🚀 go-pugleaf

Sektor van Skijlen wrote:

> Dnia Sun, 04 Mar 2007 19:37:50 +0100, Mariusz Lotko skrobie:
>> Adam Karpierz wrote:
> 
>> > "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid>
>> > wrote:
>> >>> 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ść.
> 
>> Tu się nie zgodzę. W przypadku C++ porównuje się zawsze wartość
>> obiektu. W przypadku wskaźnika wartością jest adres obiektu na
>> jaki wskaźnik wskazuje.
> 
> No tak, ale jeśli porównujesz wartości wskaźnikowe, to de facto
> porównujesz tożsamości dwóch obiektów.
> 
> Np. porównując "a == b" nie porównujesz "a" z "b", tylko porównujesz
> "tożsamość obiektu widocznego pod a" i "tożsamość obiektu widocznego pod
> b".

A jeśli obiektami są smart pointery, to co porównuję?

> 
> Zresztą to się odnosi, jak słusznie zauważyłeś, ogólnie do wartości. Jeśli
> porównujesz dowolne dwa a i b tego samego typu, to porównanie określa ci,
> czy pod tymi dwiema zmiennymi siedzą te same wartości. W przypadku
> wskaźników będzie to oznaczało tylko to, czy te dwie zmienne wskaźnikowe
> wskazują na ten sam obiekt (czy na dwa różne). Jest to więc w efekcie
> porównanie tożsamości.
> 
>> Operator == dla dwóch obiektów powinien _zawsze_ porównywać równość
>> semantyczną ich _zawartości_, a nie kombinować z ich tożsamością.
> 
> Moment.
> 
> Po pierwsze, równość dwóch obiektów powinna wynikać z równości ich
> wartości. Jeśli obiekt nie ma wartości, to nie powinien mieć określonej
> porównywalności, bo po prostu nie ma czego porównać. Porównujemy więc
> WARTOŚĆ (a nie za-WARTOŚĆ).

OK, w takim razie jakiś przykład obiektu bez wartości?

> Po drugie, nie ma akurat kombinowania z tożsamością - jeśli mamy np. (no,
> weźmy teraz Javę dla odmiany) dwie zmienne referencyjne, to ich porównanie
> nie porównuje tych zmiennych referencyjnych, tylko ich wartości, a w
> efekcie porównuje się tożsamości obiektów.

Zgoda, z tym, że ja pisałem o C++.

> 
>> Nie widzę szczególnego powodu, żeby wskaźniki nazywać "obiektami
>> niewartościowymi", skoro pełnią one funkcję referencji, czy jak
>> kto woli, identyfikatora obiektu.
> 
> Ależ wskaźniki są jak najbardziej typami wartościowymi, tylko i wyłącznie!
> 
> Tylko obiekty, które są przez te wskaźniki wskazywane, już niekoniecznie.
> W szczególności, w idealnym projekcie powinno być tak, żeby wskaźnik nie
> był potrzebny do czegokolwiek poza przyczynami czysto językowymi (czyli,
> inaczej, żeby wartość tego wskaźnika w ogóle nikogo nie musiała
> interesować).
> 
>> Każdą dowolną parę obiektów można w prosty sposób zweryfikować
>> pod kątem "czy to te same obiekty" mając do nich referencję, np.
> 
>> bool teSame(const Klasa& a, const Klasa& b)
>> {
>>         return &a == &b;
>> }
> 
>> lub czy to równe obiekty
>> a == b
> 
>> Co odpowiada konstrukcjom z Pythona jakie podalem w poprzednim poście.
> 
> Można - tyle że tej pierwszej konstrukcji nikt nie stosuje.

Że jak? Piersza linijka większości porządnych operatorów == ! Po co
porównywać zawartość tego samego obiektu?

> W Javie np. masz:
> 
> Klasa a, b;
> int c, d;
> 
> i masz
> a == b
> c == d
> 
> i bez różnicy. Szkoda tylko, że dla "String t, s" jest to samo ;)
> 
> Nie możesz jednak w żaden sposob (inny niż przez odpowiednie metody)
> porównać wartości a i b, ani porównać referencji c i d.

W C++ też musisz wiedzieć co porównujesz. Bo jeśli a i b są wskażnikami,
to masz analogiczny problem. Z tym, że zamiast equals() używasz * do
wyłuskania wartości.

> W Javie zresztą jest to urządzone niemal idealnie pod tym względem, tylko
> z drobnymi zastrzeżeniami:
> 
>  - Java nie pozwala na definiowanie własnych typów wartościowych
>  - Nie wprowadzono mechanizmu tupli, które mogłyby zastąpić niemożliwość
>    przekazania do metody zmiennej przez referencję

Od roku programuję w Javie, jakoś nieszczególnie mi to przeszkadza.

>> > Wiec jest doklandie odwrotnie niz piszesz:
>> > 
>> > Chodzi o to, że maja być dostępny inny oparator do porownania
>> > wartosci a inny do porownania tozsamosci obiektow
> 
>> Tak by było rzeczywiście najlepiej. Ale uważam, że operator == jest
>> i tak lepszy w C++ niż w Javie. Bo niby dlaczego logiczna równość
>> miałaby dotyczyć wyłącznie relacji bycia tym samym obiektem?
>> Idealnie jest to w Pythonie: operator == jak w C++ i operator "is"
>> jak w Javie.
> 
> 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.
> 
> Pierwsze nie ma sensu dlatego, że jeśli w typach wartościowych liczy się
> dla nas wartość, to nie liczy się tożsamość. Porównując wartość do
> wspomnianego koloru, interesuje nas kolor, a nie np. czy kartki papieru,
> na których zapisano kod koloru, są te same, czy inne.

W szczególności może się zdarzyć, że będziemy chcieli porównać kolor tego
samego egzemplarza kartki. Wówczas porównanie będzie prostsze i wykonalne
nawet dla daltonisty. Stąd chyba nie warto od tożsamości się odcinać.

> Drugie z kolei nie ma sensu dlatego, że porównania obiektów, jeśli już
> istnieją, to zazwyczaj mają zupełnie inny wymiar. Jeśli już coś
> porównujemy, to porównujemy stany, najczęściej określone stany cząstkowe.
> Np. możemy porównywać samochody pod względem tego, czy są tego samego
> koloru, albo tej samej marki, a także, czy jeden ma lepszego kopa od
> drugiego. Ale nie bardzo możemy "porównać dwa samochody", no bo jak?
>
> Nawet w przypadku porządkowania obiektów, mamy do czynienia z określaniem
> odpowiedniego kryterium porządkowania. Kryterium może być określone nawet
> wielopoziomowo (np. uszeregować samochody wg marki, a jak są tej samej
> marki to wg mocy silnika, a jak są nadal te same, to wg koloru itd.).
> 
> Dlatego właśnie obiekty nie mają zwykle takiej ogólnej "wartości", mają
> ich zwykle wiele i różne wartości mogą nas interesować przy porównaniach.

Piszesz trochę w kontekście bazodanowym, gdzie jest np. poszukiwanie
obiektów spełniających określone kryteria. Jest jednak cała gama klas,
dla których bez większych trudności można zdefiniować operatory porównania.

Mimo to nie odważyłbym się na takie wyraźne i jednoznaczne nazwanie
pierwszych obiektów wartościowymi a drugich niewartościowymi.

> 
> Ja wiem, że zaraz ktoś rzuci szczególnym przypadkiem, że co z obiektami,
> które mają jedno pole, a zatem tylko jeden stan cząstkowy?
> 
> Otóż tutaj właśnie odgrywa rolę kwestia tożsamości obiektów. Jeśli bowiem
> interesuje nas tożsamość obiektu, to nie interesuje nas jego wartość
> (jeśli nie podlega ona bieżącemu przetwarzaniu, tzn. np. właśnie
> chcielibyśmy tą wartość porównać z odpowiadającym temu czemuś stanem w
> innym obiekcie).

Weźmy obiekty w rodzaju mutable string. Da się jednoznacznie zdefiniować
operator porównania, w pewnej chwili dwa obiekty będą równe, a za chwilę
nie, więc trudno tu mówić o tożsamości.

> Natomiast porównanie stanów dwóch obiektów nie ma po prostu sensu. Co na
> przykład da ci informacja, że pewne dwa samochody są "tego samego koloru",
> dopóki nie wiesz, jaki to kolor?

Uwierz mi, w wielu sytuacjach ma to sens. Dziwię się Twoją opinią, bo
sprawiasz wrażenie człowieka, który ma doświadczenie zawodowe i trochę
linii kodu wyprodukował.

> 
>> > Podobnie chodzi o to aby byl dostepny inny operator do
>> > 'clone' obiektu a inny do zmiany referencji
> 
>> To też jest w C++ rozgraniczone:
>> C o1 = inny; // kopiowanie obiektu
>> C* o2 = &inny; // przypisywanie "referencji".
>> C& o3 = inny; // przypisywanie referencji.
> 
>> Schody zaczynają się, gdybyśmy napisali
>> o3 = jeszcze_inny; // ... bo to już znowu jest kopiowanie, a nie zmiana
>>                         // referencji
> 
>> No ale taki już jest ten C++...
> 
> Ale w C++ zwykle - poza szczególnymi przypadkami - nie stosuje się dla
> tego samego typu operowania statycznego i dynamicznego. Czyli, jeśli
> używamy wskaźników i new, to obiektów tego samego typu już nie tworzymy na
> stosie.

A "my" stosujemy, jeśli jest taka potrzeba... :-)


-- 
Mariusz Lotko