🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:
> [...]
> Dlaczego Java zakłada, że dla żadnej klasy to już nie byłoby efektywne?
> Właśnie to dla mnie ją dyskwalifikuje.

Chwila moment - Java nic nie zakłada. To tylko Ty zakładasz, że operator
przypisania ma działać stosownie jak zechcesz, że język ma się dawać
formować tak jak zechcesz. Mnie przykładowo to nie jest tak bardzo
potrzebne. Jeśli chcę zrobić kopię obiektu, to robię kopię obiektu, ale
wiem, że nie służy do tego operator przypisania. Dla mnie jest to
różnica polegająca na tym, że zapis, który powoduje utworzenie nowego
obiektu będącego kopią innego obiektu jest ściśle logiczny. Przykład:
Jak chcę mieć dwa obiekty typu String, drugi zainicjowany pierwszym, to
piszę:
str2 = new String(str1);
Jak chcę przypiąć obiekt identyfikowany przez str1 do identyfikatora
str2 to piszę:
str2 = str1;

Java nie wyklucza możliwości zastosowania pierwszej konstrukcji, tylko
narzuca ścisłe rozróżnienie zapisu. Najwyraźniej przeszkadza Ci, że nie
możesz operacji kopiowania uczynić niewidoczną dla oglądającego kod.
 
> Zabieranie jakiejś możliwości jest niewątpliwą zaletą tylko wtedy, kiedy
> ta możliwość nigdy nie jest warta użycia. W tym miejscu tak nie jest.

Na razie mówisz o zabieraniu możliwości pełnej dowolności w leksykalnym
odwzorowaniu różnych czynności, a w szczególności uczynieniu zupełnie
różnych czynności nierozróżnialnymi. A idziesz nawet tak daleko, że...
 
> To jest wskaźnik, bo przypisanie (jak z porównaniem?) kopiuje adres, a nie
> zawartość.

...różnicę między wskaźnikiem a referencją ograniczasz do leksykalnej
funkcji operatora przypisania.
Już myślałem, że dla potrzeb dyskusji zgodziliśmy się, że wskaźnik jest
po prostu pewnym obiektem składającym się wyłącznie z referencji do
innego obiektu. 
 
> Wręcz przeciwnie. To jest przykład na to, jak obiektowe postrzeganie
> programowania nakłada sztuczne ograniczenia.

Masz absolutną rację co do jednego - całość obiektowej filozofii
programowania to zbiór ograniczeń, które bardzo istotnie ukrócają
swobodę programisty. Ja nie mam nic przeciwko dopóki mam na tyle
swobody, że jestem w stanie zaimplementować dowolny algorytm. Natomiast
pełna i absolutna swoboda w formułowaniu zapisu, to jest krótko mówiąc
anarchia. Nie mam nic przeciwko pełnej dowolności w konstruowaniu
własnych algorytmów. Na własne potrzeby też robię wszystko tak jak mi
się podoba. Jednakże w miarę wzrostu złożoności programów doceniam
czasem fakt, że nie korzystam z pełnej swobody oferowanej przez język
programowania. A jeszcze częściej doceniam to, że inni muszą działać w
ograniczonym zbiorze "środków wyrazu", kiedy mam okazję z kimś
współpracować.
 
> Bardziej praktycznym przykładem swap(a,b), które jest mniej więcej
> równoważne:
>   temp = a;
>   a = b;
>   b = temp;
> gdzie temp jest zmienną lokalną odpowiedniego typu. Nie da się? A więc
> dziękuję bardzo za taki język. Nawet w Pascalu da się to zrobić (prawda,
> że dla każdego konkretnego typu z osobna; czy w Javie są jakieś szablony,
> czy też są tylko funkcje wirtualne i każdy typ jawnie musi określić, że
> będzie mógł być używany jako wartość porównywalna?).

Znów czepiasz się o sens leksykalny (że nie da się zapisać trzech
operacji za pomocą jednego magicznego operatora). A odnośnie szablonów -
chcesz przykład do czego prowadzi stosowanie szablonów? Idealny przykład
to MICO, które mocno korzysta z templates, dlatego że korzysta z STL-a.
I okazuje się, że nie nie trzeba dużo wysiłku, aby zupełnie prosty
programik zajmował setki kilobajtów kodu. Ja swojego czasu mocno się
zdziwiłem jak się okazało, że jeden Java-ORB okazał się parę razy
szybszy od MICO. No ale cóż - podejrzewam, że kod wersji Javowej mieścił
mi się w większej części w cache-u procesora. A nie wspominam już o tym,
że gdyby w C++ istniał praprzodek obiektowy tak, jak np. w Smalltalku,
Javie, Objective-C czy jeszcze wielu innych językach, to możnaby się
pozbyć połowy templates z programów. Drugą połowę templates można
wywalić, kiedy programiści nauczą się, że generalizacja problemów jest
również osiągalna przez wyróżnianie ogólniejszych klas. Templates są
najczęściej kolejnym sposobem na bałagan. Zamiast wprowadzać klasy typu
Comparable, prościej zrealizować funkcje Min i Max stosując szkielety.
Wtedy, jak program się gdzieś nie zechce skompilować z braku operatora
<>, to po prostu się go dopisze. Najczęściej tak to działa.

Dlatego, że w C++ istniał od zawsze bałagan (możesz nazwać go swobodą),
to pojawiła się potrzeba stosowania templates. Zastanawiałeś się
dlaczego ten mechanizm istnieje tylko w C++? Podpowiem - bo nie ma
drugiego tak bałaganiarskiego języka. ;-)
 
> Wręcz przeciwnie. To jest przykład na to, że logika przynależności metod
> do obiektów jest ograniczona i nie odpowiada dobrze rzeczywistości.
> 
> Ja rozumiem, że inni mogą lubić co innego i kochają ograniczenia
> programowania obiektowego. Nie będę im wchodził w drogę ani próbował siłą
> nawracać; przepraszam za ten kawałek świętej wojny na pl.comp.objects
> (jednak potrzeba nam pl.comp.lang.advocacy!). To jest tylko moje skromne
> zdanie i efekt długich przemyśleń.

To jest tzw. odwracanie kota ogonem (chodzi mi o to kochanie oganiczeń).
Czy kochasz jeździć prawą stroną jezdni (mam na myśli Polskę)? To
dlaczego tak jeździsz? Ano tylko dlatego, że nie jesteś sam na świecie i
mógłbyś się z kimś zderzyć. Temu służą pewne ograniczenia. Na dodatek
ograniczenia w programowaniu służą też temu, żebyś nie zderzył się z
samym sobą, kiedy za jakichś czas zapomnisz o prywatnej logice
zastosowanej w jakimś projekcie.

Jeszcze odnośnie tego przywiązania metod do obiektów. Bardzo proszę -
masz zwykłe C. Tam żadna metoda nie jest przywiązana do żadnego obiektu.
Po prostu każda metoda operuje na pewnym zestawie obiektów i tylko tyle.
Czy dobrze rozumiem, że jedyna wyższość C++ polega na tym, że można na
dodatek tworzyć jeszcze funkcje o jednoliterowych, nic nie mówiących
nazwach jak + - * < > << >> ... itp? Acha - i są jeszcze templates :-)

BTW. Żeby uwolnić psychikę programistów przyzwyczajonych do funkcji,
niektóre języki idą tak daleko, że przestają nazywać funkcję metodą, a
zastępują ją komunikatem lub wiadomością. One mają to do siebie, że
znajdują się znacznie bliżej istoty efektywnego programowania, tj.
interakcji między obiektami wyrażanej jako przesyłanie między nimi
komunikatów. I wbrew pozorom w tym wszystkim jest logika. Kiedy
zaczniesz patrzeć na program jako na taką interakcję, to znacznie
łatwiej jest wykonać jego dekompozycję na części składowe. Możesz zacząć
się koncentrować na logice obsługi pojedynczych komunikatów, łączyć
interakcję w coraz większe fragmenty, a najważniejsze, że przestajesz
patrzeć na program jako jeden wielki ciąg instrukcji.

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