🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:
> [...]
> Z powyższej składni wynika, że nie da się zawrzeć jednego obiektu wewnątrz
> drugiego. Można najwyżej umieścić referencję do niego. O ile następnik
> mógłby być referencją albo wskaźnikiem, o tyle właściwe dane elementu
> listy są w naturalny sposób częścią tego elementu, a nie są tylko do niego
> podłączone.

Hmm, nie do końca rozumiem, co rozumiesz przez zawieranie. Java pozwala
na stosowanie klas wewnętrznych, co pozwala na wsadzanie jednych klas do
drugich. Z tym, że raczej nie stosuje się tego dla zwiększenia szybkości
dostępu, a raczej dla zmiany uprawnień dostępu.
 
> Z powyższej składni wynika, że operator = tworzy nową referencję, a nie
> kopiuje obiektu. Czy tak samo jest dla liczb całkowitych?

Nie tworzy nowej referencji, ale kopiuje referencję. To istotna różnica.
Oczywiście kopiowanie referencji ma miejsce tylko wtedy, gdy po obu
stronach operatora mamy typy obiektowe. Ze względu na to, że nie byłoby
efektywne posługiwanie się w ten sposób typami prymitywnymi, tj. byte,
int, long, float itp, to w przypadku zastosowania operatora przypisania
mamy do czynienia z kopiowaniem przez wartość.
 
> * Jeśli tak, to to musi być bardzo nieefektywne. Przy każdej operacji
>   typu a=b+c obiekt jest niszczony i tworzony na nowo.

Jeśli mamy do czynienia z wyżej wymienionymi typami, to operacja odbywa
się na wartościach. 

> * Jeśli nie, to znaczy, że pewne typy wbudowane pracują na innych prawach
>   niż wszystkie typy definiowane przez użytkownika (AFAIK właśnie tak jest
>   w Javie). Dla mnie to jest nienormalne z założenia.

Fakt, z punktu widzenia programisty nienormalne jest to, że musi
rozróżniać Integer od int. Jednakże te drobne niewygody redukuje fakt,
że progamista dostaje narzędzie, które po prostu z góry narzuca mu
wielokrotne wykorzystywanie tych samych obiektów. W przeciętnym
projekcie C++ jest znacznie więcej niepotrzebnego kopiowania całych
obiektów, a nie referencji. W wielu wypadkach robi się kopie tylko
dlatego, że później nie będzie wiadomo, kto ten obiekt ma tak naprawdę
skasować. 
 
> W każdym razie wygląda na to, że w Javie nie ma referencji, przynajmniej
> dla typów definiowanych przez użytkownika. Są same wskaźniki! Tyle że tego
> na oko nie widać, bo każda funkcja oczekuje tych wskaźników i wskazywane
> obiekty same się zwalniają.

Tego zdania też nie rozumiem. Jeśli jakiś obiekt jest czymś
identyfikowany i tenże identyfikator jest utożsamiany z obiektem, bez
pośrednictwa dodatkowych operatorów, to dla mnie to jest referencja.

> Załóżmy, że chcę zdefiniować operację przypisz, która działa jak operator
> przypisania, tzn.
>   a.przypisz (b);
> jest dokładnie równoważne
>   a = b;
> albo drugą wersję, która jest równoważna
>   b = a;
> W szczególności jeśli dla pierwszej wersji wcześniej było c = a (a dla
> drugiej c = b), to teraz wartość c ma się nie zmienić (mam nadzieję, że
> dobrze rozumiem znaczenie = w Javie, której nie znam). Jak to zrobić?

Hmm, to jest właśnie doskonały przykład tego jak C++ może wykoślawić
obiektowe postrzeganie programowania. Rozumiem, że jest tak: Mamy dwa
różne obiekty, i wywołanie metody jednego z tych obiektów ma spowodować,
że tenże obiekt stanie się drugim obiektem. Czyli po tejże operacji
referencja identyfikowana przez zmienną a będzie równa referencji b. To
jest absolutnie sprzeczne z logiką projektowania obiektowego. W
pierwszej z brzegu książce trąbi się o tym, że metoda jest funkcją
wywoływaną na rzecz obiektu. I to stwierdzenie jest tu kluczowe. Można
oczekiwać, że metoda przypisz będzie co najwyżej kopiowała wartości
atrybutów z obiektu b. Natomiast jeśli metoda działająca na rzecz
obiektu ma się tego obiektu pozbyć i pod identyfikator, który chwilowo
ten obiekt identyfikuje podstawić coś zupełnie innego, to wybacz, ale
jest to absolutnie sprzeczne z całą logiką obiektowości. Jak chcesz
wykorzystać identyfikator a do tego, żeby wskazywał na obiekt
identyfikowany zmienną b, to korzystasz z operatora przypisania. Bo on
do tego służy.

Tak apropos niedawnej dyskusji na temat friendów - C++ wprowadza
kolosalny bałagan w sensie tego, że możesz sobie wszystko
przedefiniować. To powoduje, że ktoś sobie w pewnym momencie wprowadza
np. operator pisania do strumienia jako operator dwuargumentowy, bo tak
mu się wydaje ładnie. Co z tego, że jest ładnie, skoro natychmiast
okazuje się, że tak pokręcony operator zerwał z logiką przynależności
metod do obiektów i trzeba wymyśleć mechanizm zaprzyjaźniania, żeby go z
powrotem "przykleić" do tych obiektów, z których został wyrwany. 

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *   POLAND