🚀 go-pugleaf

Sektor van Skijlen wrote:

> Dnia Sun, 04 Mar 2007 17:46:12 +0100, Marcin 'Qrczak' Kowalczyk skrobie:
>> Dnia 04-03-2007, nie o godzinie 14:50 +0000, Sektor van Skijlen
>> napisał(a):
> 
>> > > if obj is anotherObj : # sprawdza czy to te same obiekty
>> > > if obj == anotherObj : # sprawdza czy zawartość obiektów jest równa.
>> > 
>> > > Czy o to Ci chodzi?
>> > 
>> > Właśnie NIE o to mi chodzi. Chodzi o to, że ma być dostępny TYLKO
>> > operator ==, natomiast od definicji typu zależy czy porównuje on
>> > tożsamość, czy wartość.
> 
>> To się sprawdza, ale tylko w językach, w których podstawowe wartości są
>> realizowane przez obiekty immutable. Jeśli tak nie jest, czyli kiedy
>> typ, który powinien być typem wartościowym, jest realizowany jako obiekt
>> ze stanem, czyli kiedy ten obiekt ze stanem tak naprawdę modeluje
>> zmienną tego typu, a nie wartość tego typu, to mamy konflikt: równość
>> zmiennych powinna porównywać zmienne jako takie, ale częściej chcemy
>> porównywać bieżące wartości tych zmiennych i to zazwyczaj robi operator
>> ==. Czyli po pierwsze działa niezgodnie z ogólnymi wytycznymi, a po
>> drugie porównanie zmiennych w razie czego też powinno być dostępne.
> 
> Ha! W razie czego!
> 
> No właśnie o to chodzi, że nie. Jeśli określamy dany typ jako wartościowy,
> to tożsamość przechowującego ją obiektu nie powinna nas interesować w
> ogóle.

A zatem powszechnie stosowany "trik" polegający na sprawdzeniu tożsamości
obiektu w pierszej linijce operatora == uważasz za błędny?
Podobnie w operatorze =, w którym zapobiega to przypisania obiektu
samemu sobie?

> Jeśli jest to potrzebne do jakichś wewnętrznych operacji, to powinno być
> dostępne w inny sposób, jakimś specjalnym interfejsem, dostępnym tylko
> wewnątrz implementacji. Użytkownik powinien dostać do tego standardowe
> API, z operatorem porównania porównującym wartości.
> 
> Zauważ, po co w C++ stosuje się wskaźniki i referencje do takich typów jak
> int, czy std::string. Jeśli już, to stosuje się albo uogólnienie
> przekazywania (const T&), albo przekazuje się do zmodyfikowania (T&, T*).
> Czy widziałeś kiedykolwiek w jakimś rzeczywistym programie, żeby ktoś
> porównywał dwa wskaźniki do int (pomijając przypadek, gdy wskaźnik do int
> jest używany jako iterator do tablicy int-ów - czyli zastosowanie jest
> inne, niż wartość referencji)?

Tak, w dowolnej konkretyzacji szablonu int'em. Nie każdemu chce się
robić specjalne implementacje dla typów prostych.

> Dlatego tożsamością dla obiektów wartościowych jest wartość. Obiekty mogą
> sobie tą wartość przekazywać jak chcą, a nawet - jak pamiętasz,
> dyskutowaliśmy o tym - wartości mogą być symulowane przez predefiniowane
> unikalne obiekty i w takim przypadku porównanie tożsamości takich obiektów
> jest równoważne porównaniu wartości, choć to już jest szczegół
> implementacyjny.

Nie zgadzam się. Każdy obiekt jest uproszczeniem rzeczywistości, a co za tym
idzie z dużym prawdopodobieństwem mogą pojawić się obiekty o tych samych
wartościach, które nie są tymi samymi obiektami.
To, że mam kolor oczu jak Brad Pitt nie czyni mnie Bradem
Pitem o czym zaświadczy każdy stosowny operator porównania - tu: kobieta ;-)

A poważnie: trzymajmy się terminologii, która była, jest i sprawdza się:
obiekt (zestaw wartości) i identyfikator obiektu (tożsamość). Nie twórzmy
nowych teorii na temat abstrakcji, która już została odpowiednio
steoretyzowna. 


-- 
Mariusz Lotko