🚀 go-pugleaf

Dnia Sat, 12 Nov 2005 14:17:40 +0100, Marcin 'Qrczak' Kowalczyk skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> > Co, że niby 16, {16} i "16" czymś się różnią pod względem wartości
> > wynikowej, czy też typu, jaki posiada zmienna ustawiona komendą set,
> > której podajesz tą wartość?

> W tym sęk, że się nie różnią: koncepcyjnie wszystkie są stringami.

> Operator == (ściślej: if, widząc napis z == jako operatorem) sprawdza,
> czy oba stringi wyglądają jak liczby.

Właśnie nie do końca jest tak. W moomencie gdy wykonujesz komendę "set", to
już wtedy jest dokonane sprawdzenie, czy to wygląda jak liczba. Oczywiście w
obiekcie Tcl-owym jest przechowywany zarówno string w takiej postaci, w jakiej
podano go do set, ale także liczba całkowita.

Ponieważ string uważa się za podstawowy sposób przechowywania informacji, więc
jego zawężenie 'typ całkowity' uważa się za typ tego obiektu.

> Jeśli tak, to porównuje ich
> liczbowe wartości. Jeśli nie, to porównuje je jako stringi. Z tego

Jeśli przypadkiem mogłoby się zdarzyć, że dany string "nie jest liczbą", to
następuje próba dokonania domyślnej konwersji na liczbę. Jeśli się nie
powiedzie, to jest to string. Ale z tego, co ja się ostatnio orientuję, to
taka operacja w ogóle nie ma miejsca w operatorze ==, ani w ogóle w arytmetyce
(właśnie dlatego stanowczo doradza się, żeby argument do komendy expr szedł w
klamrach, bo wtedy wykonuje się szybciej). Ma za to miejsce we wszelkich
'set-ach' (czyli również incr i append).

Przykładowo: jeśli dwie zmienne przechowują jakieś liczby i zostanie wykonana
operacja arytmetyczna na ich wartościach, a nowa zostanie zwrócona przez
wartość i wpisana do innej zmiennej, to w tym wszystkim może się ani razu nie
odbyć konwersja int -> string (ani tym bardziej odwrotnie). Wartość zostanie
zwrócona przez obiekt Tcl-owy, a wykonujące się tu operacje są wyłącznie
zainteresowane wartością całkowitą; to, czy ten obiekt przechowuje wartość
również w wersji stringa, to ich serdecznie wali.

> powodu używanie go do sprawdzania równości stringów jest ryzykowne,
> chyba że statycznie wiemy, że któryś string nie wygląda jak liczba.

Zazwyczaj tak jest. Jeśli porównujemy ze "statycznym" stringiem, który widać,
że nie jest liczbą, to możemy bezpiecznie używać operatora ==. Operatora eq
należy używać tylko gdy porównujemy arbitralne stringi, albo wiemy że
porównujemy liczby, a chcemy je porównać co do znaku.

> W Perlu liczby też są traktowane jako podzbiór stringów. Poza nimi

Tak, tylko że tam konwersja stringa na liczbę nie rzuca wyjątkiem w razie
niepowodzenia, tylko zwraca wartość 0.

> Perl ma jednak referencje na inne obiekty, a Tcl również je symuluje
> napisami.

Też nie do końca masz rację. Te referencje są jedynie REPREZENTOWALNE jako
stringi. Po prostu w Tcl-u każda wartość musi być jedynie reprezentowalna jako
string. Ale wcale to nie oznacza, że dane przechowuje się tylko jako stringi.

> Prawie wszystkie dynamicznie typowane języki (poza Perlem, Tclem
> i uniksowymi szelami) używają wielu rozłącznych typów. Dzięki temu
> podanie wartości złego typu jest zwykle wykryte w czasie wykonania.
> Dzięki temu też można programować obiektowo również na podstawowych
> typach: jeden zapis abstrakcyjnej operacji (np. równości albo
> mniejszości) ma różną interpretację w zależności od typów obiektów.

No tak, ale potrafi ją rozpoznać. I o to właśnie chodzi. Na takiej samej
zasadzie działa == w Tcl-u.

> Jeśli natomiast koncepcyjnie różne wartości są modelowane przez
> włożenie do tego samego typu (stringu), to trzeba jawnie określić,
> o którą interpretację chodzi, przez wybór operacji, a pomyłki w tym
> zakresie nie są wykrywane.

Nie no teoretycznie mógłbyś spróbować zrobić [read 0]. Ale wartość "0"
momentalnie zostanie wykryta jako niepoprawny deskryptor pliku.

Problem jest tylko wtedy gdy budujesz np. strukturę drzewiastą, gdzie wieszasz
różne obiekty, których typy jakoś musiałbyś rozpoznać. Można tu stosować różne
metody, w tym wieszać tylko identyfikatory obiektów IncrTcl i odpytywać je
przez isa (lub po prostu kazać im zrobić konkretne rzeczy).

> Gdyby == w Tcl było błędem na stringach nie wyglądających jak liczby,
> to przynajmniej błędy w jedną stronę byłyby wykrywane.

Nie no można byłoby zrobić tak, można było zrobić "fallback" do porównania
stringów, co zrobiono.

Zawsze możesz np. napisać:

if { $a+0 == $b }

i wtedy dostaniesz wyjątek, jeśli '$a' nie wygląda jak liczba. A sprawdzać czy
$b jest liczbą już i tak nie musisz, bo jak nie będzie liczbą, to porównanie
zwróci false.

> > W momencie set-a. Jeśli uważasz, że w innych momentach, to masz
> > nieaktualne informacje (może tak było w poprzednich wersjach Tcl-a,
> > obecnie jest tak).

> To jest szczegół implementacyjny, którego nie widać w semantyce.

Wiesz, to wszystko zależy.

Jeśli mówimy, że wszystko jest stringiem, to możemy powiedzieć, że typizacji
nie ma.

Jeśli mówimy, że każdy obiekt ma swój określony typ, a jedynie istnieje wymóg,
aby każda wartość była reprezentowalna w postaci stringa, to sytuacja wygląda
na inną, choć to semantyki faktycznie nie zmienia.

CO więc takiego jest w tej semantyce, co decydowałoby o tym, że Tcl nie
posiada typów?

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"