🚀 go-pugleaf

On Fri, 22 Jan 1999, Michal Mosiewicz wrote:

> Jak chcę mieć dwa obiekty typu String, drugi zainicjowany pierwszym,
> to piszę:
> str2 = new String(str1);

I jest to mniej efektywne. W ruch wchodzi gc, nawet kiedy czas życia
obiektu pokrywa się z zakresem widoczności odpowiedniej zmiennej.
Zajmuje więcej pamięci.

> Ja nie mam nic przeciwko dopóki mam na tyle swobody, że jestem w
> stanie zaimplementować dowolny algorytm.

Mnie to nie wystarcza. Dowolny algorytm można zaimplementować
i na maszynie Turinga, co nie znaczy, że tak jest najwygodniej
i najefektywniej.

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

Kosztem braku kontroli typów w czasie kompilacji? Dziękuję bardzo.

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

Czyż nie jest tak, że np. funkcja obliczająca wartość haszującą obiektu
nie jest potrzebna - do czasu, kiedy zechcemy użyć go jako klucza
w tablicy haszującej? Dla mnie nienormalna jest konieczność pomyślenia
zawczasu o wszystkich operacjach, jakie na obiekcie planuję wykonywać,
i wyliczenia wszystkich interfejsów, jakie te obiekty będą implementować.

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

Ale nie ma (wygodnego) polimorfizmu. Do którego bynajmniej nie jest
potrzebne przywiązanie każdej operacji do jakiegoś obiektu!

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

Polimorfizm. Konwersje typów (w tym dziedziczenie). Konstruktory
i destruktory. Przeciążanie funkcji. Referencje (wiem, że to czysto
składniowa sprawa, funkcjonalnie emulowalna przez wskaźniki). Szerzej
stosowana kontrola typów. I dużo pomniejszych drobiazgów.

Nie, wcale nie kocham C++. Głównie nie lubię skomplikowania i paskudnej
składni, zaszłości z C i braku (jest na tyle mało elastyczny, że z brakiem
możliwości samodzielnego zdefiniowania) mnóstwa drobiazgów i paru bardziej
podstawowych mechanizmów: interfejsów, których nie trzeba jawnie
dziedziczyć, funkcji konstruowanych w locie, funkcji w funkcji.

A operatora + służącego do dodawania liczb zespolonych nie uznasz chyba za
nic nie mówiący. Przeciążanie operatorów już jest - dla typów wbudowanych.
Szczególne prawa dla typów wbudowanych są według mnie nienormalną zasadą.

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

W Javie tak podstawowa operacja jak przypisanie nie jest wysłaniem
komunikatu. Niestety podzielenia przez siebie dwóch liczb zespolonych
w żaden sposób nie wyobrażę sobie jako przesłania komunikatu (kto do
kogo?). A do zapisania tekstu na strumień nie wiadomo, czy mamy wysłać
komunikat do strumienia, pokazując mu tekst, czy do tekstu, pokazując jej
strumień.

To może i bywa odpowiedni sposób myślenia o pewnych sprawach na wysokim
poziomie abstrakcji, ale nie nadaje się jako sposób na wszystko. Z drugiej
strony, funkcje, które formalnie nie wyróżniają żadnego argumentu, po
dodaniu polimorfizmu itp. wyrażają wszystko to, co komunikaty, a nawet
więcej (w moim modelu wiele rzeczy wyrażają dosyć inaczej - hierarchia
interfejsów jest niezależna od hierarchii implementacji).

-- 
 __("<    Marcin Kowalczyk * qrczak@knm.org.pl http://kki.net.pl/qrczak/
 \__/       GCS/M d- s+:-- a21 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-