🚀 go-pugleaf

Dnia Tue, 06 Mar 2007 00:36:01 +0100, Marcin 'Qrczak' Kowalczyk skrobie:
> Dnia 04-03-2007, nie o godzinie 22:09 +0000, Sektor van Skijlen
> napisał(a):

> > Tak, tylko że jeśli "wierzymy w podział na obiekty wartościowe i
> > niewartościowe" (czytaj: mamy oczy tam gdzie trzeba), to relacja 'is' w
> > obiektach wartościowych jest nam zbędna, a '==' w obiektach niewartościowych
> > również nie ma sensu.

> Ten idealistyczny obraz, teoretycznie słuszny, sprawia pewne trudności
> w językach, w których wiele podstawowych typów jest zmienialnych.

> (Wyjątkowo nie dotyczy to C++, które pracuje w innym paradygmacie:
> powszechnie niejawnie kopiuje obiekty, przez co zmienialność obiektów
> ma węższe konsekwencje. Przy innym stylu programowania analogie między
> językami przestają działać.)

Zgadza się - ale nie tylko dlatego. Obiekty niewartościowe jak najbardziej
występują w C++. Chodzi tylko o to, że w C++ - w odróżnieniu od większości
języków - można tworzyć własne typy wartościowe. Fakt, że każdy typ ma
domyślne traktowanie jako wartościowy, jest przykrą konsekwencją drobnego
uogólnienia (jego brak zwykle oznacza, że nie da się tworzyć własnych typów
wartościowych; w C# zrobili dobrą przymiarkę na udostępnienie tego inną
metodą, tylko niestety sprawę spartolili).

> Trudności polegają na tym, że jeśli np. jedyny typ stringów jest
> zmienialny, to formalnie przestaje być typem wartościowym. Sam
> napisałeś: ?mutable string - jeśli mówimy o czymś takim, jak
> StringBuilder - nie jest już typem wartościowym, gdyż zmienność obiektu
> wchodzi w interakcję z jego tożsamością?. Tyle że w takim języku on jest
> również powszechnie używany w roli typu wartościowego!

Ha! Wynika to z faktu, że string z natury jest typem wartościowym. Jeśli
język nie umożliwia zrobienia takiego typu wartościowego, to trzeba robić
obejścia w postaci obiektu niemodyfikowalnego.

> Prawdopodobnie
> częściej niż jako ?zmienna stringowa?. Większość użyć wykorzystuje
> zmienialność najwyżej w trakcie konstrukcji, a później taki obiekt już
> nie jest zmieniany ? za to różne moduły swobodnie przechowują wskaźniki
> do niego, zakładając, że już się nie zmieni. Porównanie jego zawartości
> staje się powszechne.

Zgadza się - ale skoro jest to obiekt niemodyfikowalny, to może być traktowany
jako typ wartościowy, gdyż zmienność w tym przypadku nie powoduje konsekwencji
wchodzenia zmienności w interakcję z tożsamością. De facto zatem, tożsamość
takich obiektów nie ma dla nas znaczenia, co wystarcza do stwierdzenia, że
jest to typ wartościowy.

Ale skoro tak, to i porównywanie tego obiektu powinno porównywać wartość, a
nie tożsamość. I tak właśnie jest w C#.

> Stąd część języków wychodzi z założenia, że będzie to bardziej
> praktycznie, jeśli domyślna równość w takim przypadku porówna zawartość.
> Czyli dla takich obiektów mamy dwa sensowne warianty równości.

Ale tylko jeden z tych wariantów ma sens. Tożsamość dwóch obiektów typu
string, jeśli to są obiekty niezmienialne, jest nieistotna - program nie
powinien w żadnym przypadku polegać na tej tożsamości.

Tożsamość jest ważna, jeśli obiekt jest zmienialny.

> Zwłaszcza że tożsamość różnych prostych typów, np. kolekcji, częściej
> istnieje na poziomie koncepcyjnym (klonujemy obiekt, kiedy mamy ochotę
> zapamiętać jego bieżący stan, ale jeszcze go zmieniać, i pilnujemy się,
> w które miejsce przekazujemy którego klona) niż w sensie jawnego
> porównania tożsamości dwóch obiektów nieznanego pochodzenia.

> Tak jest na przykład w Pythonie w przypadku list i słowników (ale nie
> stringów, które są immutable).

Nie rozumiem.

> Lisp i Scheme są zgodne z ogólną teorią, jeśli za podstawową równość
> (czy też równoważność) przyjąć EQL / eqv?; ona nie zmienia się w czasie
> i zmienialne obiekty porównuje po tożsamości, a liczby i znaki po
> wartości (niestety nie można robić własnych typów wartościowych).
> Ale ponieważ stringi, listy i tablice są dostępne wyłącznie w wersji
> zmienialnej, mamy też EQUAL / equal?, które schodzi do ich elementów,
> w dodatku rekurencyjnie z tą samą operacją.

O ile sobie przypominasz, w którejś z naszych wcześniejszych dyskusji nawet
zgodziliśmy się co do tego.

Różnica polega jedynie na tym, czy można tworzyć własne typy wartościowe i czy
można obiekty wartościowe modyfikować w miejscu. Ale te sprawy są już ściśle
związane z określonymi ficzerami językowymi.

Jeśli język umożliwiałby tylko chociażby możliwość definiowania własnych typów
wartościowych, to rozróżnianie porównania tożsamości i porównania wartości nie
byłoby potrzebne. Śmiem wręcz twierdzić, że wystarczyłaby do tego konstrukcja
językowa, która tak stanowi i jednocześnie uniemożliwia modyfikację takiego
obiektu.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"