🚀 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