🚀 go-pugleaf

Dnia Sat, 2 Sep 2006 22:56:02 +0200, Michal Przybylek skrobie:
> "Marcin Stefaniak" <matmis@gazeta.SKASUJ-TO.pl> wrote:

> > Tak mi się w każdym razie wydaje.

> Nie tu chodzi o cos innego. Duzo bardziej fundamentalnego.

> Roznica jest duzo bardziej fundamentalna. C++ nie ma parametrycznego
> polimorfizmu tylko makrogenerator, ktory niejako przypadkowo okazal sie miec
> funkcjonalnosc rownowazna parametrycznemu polimorfizmowi.

lol ;) merytoryczne aż do bólu.

> W paramatrycznym polimorfizmie istotne jest to, ze mamy _jedna_ dostatecznie
> bogata funkcje o porzadnych wlasnosciach.

Na tej samej zasadzie można udowadniać, że polimorfizm w programowaniu
obiektowym polega na tym, że mamy _jedną_ dostatecznie bogatą klasę o
porządnych właściwościach.

> W C++ dostajemy "szablon funkcji", z ktorego kompilator moze nam usluznie
> wygenerowac konkretna funkcje (ale nie wygeneruje, np. kiedy napisalismy
> specjalna wersje z reki).

Zawsze mnie bawiło, jak ktoś mówił o "generowaniu funkcji" przez kompilator.

> Standardowy parametryczny polimorfizm ma ladna interpretacje kategoryjna
> (np. w modelach PER) - jest to faibracja, w ktorej morfizmy sa _pojedynczym_
> zyjatkiem (np. w PER _jedna_ klasa rownowaznosci), nie zas kolekcja zyjatek,
> z ktorej wyciagamy to co nam jest potrzebebne po typie.

Tłumacząc ten śmieszny bełkot na normalny język: w Javie aby można było
zastosować dany typ jako parametr wzorca, to musi mieć on na starcie
odpowiednie właściwości gwarantowane (jeśli są wykorzystywane; przykład z
List<String> jest przykładem, gdzie akurat nie są wykorzystywane, poza
samym faktem, że String musi być typem klasowym). Nawiasem mówiąc, w C++
kiedyś też tak było (z tą tylko różnicą, że nie można nadawać tych gwarancji
przez deklarację koncepcji).

Ja tam na upartego dopatrywałbym się wspólnego źródła generyków Javy i wzorców
w C++, ale dalej te języki wybrały inne drogi. Można dyskutować o tym, jakie
są odpowiednie wady i zalety obu rozwiązań. Różnica jest mniej więcej taka,
jakby mieć programowanie obiektowe oparte na klasach oraz programowanie
obiektowe nie oparte na klasach, tylko każdy obiekt dostaje arbitralnie
określony komunikat i ma na niego odpowiedzieć (albo zgłosić błąd). Drugie
rozwiązanie jest bardziej generyczne, bo nie wprowadza zależności od definicji
klasy. Ale rozwiązanie z klasami jest lepsze pod tym względem, że lepiej
porządkuje kod. Oczywiście w implementacji statycznej ten fakt ma znacznie
mniejsze znaczenie.

Ale z wami przecież nie da się dyskutować inaczej, niż plując na wszystko, co
reprezentuje sobą C++, wzbogacając wszechogarniającą - jak to się p. Andrzej
Lewandowski raczył wyrazić - amatorszyznę.

> > dlaczego dla ludzi o mocnych nerwach? :-)

> Nie chce isc do pierdla, kiedy Sektor popelni samobojstwo dowiedziawszy sie
> kolejnej straszliwej prawdy...

Jasne - gdybym się przejmował takim bełkotem, jak tu powyżej to
zaprezentowałeś, to prawdopodobnie nigdy byś nie widział mnie na tej grupie.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"