🚀 go-pugleaf

Sektor van Skijlen wrote:

> Dnia Mon, 05 Mar 2007 23:58:08 +0100, Mariusz Lotko skrobie:
>> Sektor van Skijlen wrote:
> 
>> > Dnia Mon, 05 Mar 2007 07:07:55 +0100, Mariusz Lotko skrobie:
>> >> > 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?
>> > 
>> > Tak.
> 
>> Wybacz, ale powyższym stwierdzeniem skłaniasz mnie do stwierdzenia u
>> Ciebie paranoi... Przecież stosowanie tego jest oczywiste. Po co mam
>> sprawdzać, czy mam tyle samo pieniędzy w swoim portfelu co... w swoim?
> 
> Portfel nie jest typem wartościowym.
> 
> Ilość pieniędzy w portfelu jest jedynie jednym ze stanów tego obiektu,
> podobnie jak ilość kart kredytowych w środku, kolor portfela i materiał, z
> którego go wykonano.

I w _każdym_ systemie tak to modelujesz? Z pełną otoczką? Piękny przykład
wzorca "swiss army knife".

> Typem wartościowym może być kolor. Porównanie dwóch obiektów typu kolor
> można porównać ze sprawdzeniem, czy na dwóch kartkach papieru zapisany tam
> kod koloru jest ten sam. Ty chcesz, żeby przed odczytaniem numeru z każdej
> kartki najpierw sprawdzić, czy te obie kartki to czasem nie jest jedna i
> ta sama kartka. Jaki to ma sens?

Idąc Twoją logiką: niekoniecznie. Obiekt kolor ma jeszcze atrybuty: data
naniesienia, technika wykonania i stopień nasłonecznienia, które pozwalają
obliczyć rzeczywisty kolor w czasie :> Wtedy nie da się porównać dwóch
"czerwonych". Odsyłam do ekspertów - lakierników samochodowych.

>> >> Podobnie w operatorze =, w którym zapobiega to przypisania obiektu
>> >> samemu sobie?
>> > 
>> > Tu już nie, ale to jest związane z tzw. kwestią językową. W przypadku
>> > C++ jest to konieczne, jeżeli obiekt podawany jako argument operatora =
>> > jest przekazywany przez referencję.
>> > 
>> > Nie byłoby natomiast tego problemu w przypadku, gdyby ten obiekt był
>> > tam przekazywany przez wartość.
>> > 
>> > Gdyby hipotetycznie w Javie była możliwość zrobienia czegoś podobnego,
>> > to tam też nie ma konieczności dodawania takiego sprawdzenia:
> 
>> Z tym, że w obu przypadkach nie chodzi o "przykrą konieczność", a
>> o "wspaniałą możliwość" szybkiego stwierdzenia, że chodzi o "te same"
>> a więc na pewno "takie same" obiekty.
> 
> To jest przykra konieczność. Musisz to po prostu zrobić, bo inaczej będzie
> wylot.

W operatorze porównania? Nie sądzę...

> Ta "wspaniała możliwość" z kolei powoduje droższe porównanie.

W pewnych przypadkach może tak być. Implementując operator warto
oszacować prawdopodobieństwo porównywania tych samych obiektów.
Generalnie jednak - nie zgadzam się.

>> >> > 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.
>> > 
>> > Przy uogólnianiu oczywiście jest to prawda, z tą tylko różnicą, że tam
>> > typ parametryczny T traktuje się prawdopodobnie zawsze jak typ
>> > obiektowy, więc sprawa konkretyzacji na int nie ma i tak znaczenia.
> 
>> "Prawdopodobnie" to dla mnie trochę za mało. Szczególnie w przypadku
>> szablonów, które według mojej praktyki z reguły są po prostu przeznaczone
>> dla obiektów oferujących określony interfejs. I innych ograniczeń w ich
>> użyciu właściwie nie ma.
> 
> Tak, dokładnie. Ale typy wartościowe zwykle mają inny interfejs, niż typy
> obiektowe.

Znowu ogólnik: "zwykle"... "Sprzedajesz" nam teorię, która ma działać w
praktyce, ułatwiać ją. Chciałbyś, żeby Twój samochód "zwykle" działał?

> 
>> > Jeśli mówimy już o rzeczywistości - podaj mi przykład obiektu z
>> > rzeczywistości, który posiada jednocześnie wartość i tożsamość.
> 
>> Konto bankowe. Tożsamość: numer, wartość: saldo.
> 
> Oraz wartość: właściciel (można go potem kiedyś zmienić)
> Oraz obiekt: historia transakcji
> Oraz...

Jak wyżej: zależy od kontekstu. Możemy nie wiązać obiektów transakcji do
konta, a zrobić wiązanie odwrotne: każda transakcja ma referencję do konta.
I podobnie z właścicielem. Krótko mówiąc "konto jest anonimowe" i
przechowuje jedynie swoje saldo (wartość) oraz numer (tożsamość).
Nie wiem, czy to ma sens, ale nie możesz chyba wykluczyć, że w jakimś
tam systemie może mieć.

> Czy ty w ogóle wiesz, co to jest "wartość"?

Element ze zbioru (tu: typ, klasa).

>> Nie chciałbym mieć konta w banku, który ma kłopot z odróżnieniem
>> wartości mojego konta od jego tożsamości.
> 
> Na razie to masz problem z odróżnieniem wartości od stanu.

Hmm, mam na ten temat "swoją teorię". Na razie przyjmijmy, że jestem
betonem zamkniętym na Twoją światłą myśl. Na pocieszenie powiem Ci, że jeśli
Twoja teoria się przyjmie i w kilku książkach pojawią się
sformułowania w rodzaju "słynny obiektolog prof. van Skijlen opisuje to w
swojej pracy...", to zgłoszę się do Ciebie po autograf :-)

A tymczasem pozwolę sobie zakończyć, bo już chyba nikt nas nie czyta, 
a i argumenty jakby zaczęły się powtarzać.


-- 
Mariusz Lotko