🚀 go-pugleaf

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.

> 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:

class K
{
	private String s;
	public void copyFrom( K x )
	{
		s = x.s;
	}
	...
}

Wywołanie K.copyFrom( this ) nie spowoduje błędu w tym przypadku.

> > 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.

Ale jeśli jest traktowany jako typ obiektowy, a nie wartościowy, to również
istnieje przekazywanie przez referencję, czy nieużywanie operatora == (bo nie
wiadomo, czy zdefiniowany) itd. - czyli typu T nie uważa się za wartościowy.

> > 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.

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ść.

> 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 ;-)

Ale kolor oczu nie stanowi o wartości człowieka, o czym również może
zaświadczyć wspomniany operator porównania ;)

> 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. 

Ja nie tworzę żadnych nowych teorii - ja tylko obserwuję rzeczywistość.

-- 
//  _    ___         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"