🚀 go-pugleaf

Dnia Fri, 21 Oct 2005 18:27:59 +0200, jarekr skrobie:
> ten temat obrabiasz średnio raz na dwa miesiące na jakiejś grupie

W szczególności przypominam sobie dwa (zgaduję, że pierwszy był dwa miesiące
temu), a ten pierwszy był na pl.comp.lang.c.

> i absolutnie jesteś odporny na kontratak.

Z bardzo prostej przyczyny: nikt jeszcze nie podał żadnego racjonalnego
kontrargumentu. Masz okazję, chwilowo nie wiem dlaczego nie skorzystałeś.

> to że w javie, żeby wykonywać 
> operacje na funkcjach potrzeba czasem więcej linijek kodu niż w C++
> jest słabym argumentem.

Nie bądź śmieszny. To nie jest tylko "trochę więcej linijek" (nb. nie rozumiem
dlaczego fakt, że trzeba się więcej opisać w dokładnie tym samym stylu, ma być
słabym argumentem).

> (w dowolnym assemblerze wskaźnik do funkcji ustawić 
> można w jednej linijce i nawet sie typem nie trzeba przejmować !).

Ale nie rozumiem, co to ma do tematu ;)

> >>>- nie pozwala operowa? zmiennymi typów ?cis?ych (jedynie ich warto?ciami)
> > 
> > 
> >>Ze co?...
> > 
> > 
> > Przekaż mi pan zmienną do metody. Tak, żeby metoda mogła ją zapisać.
> > 
> Panu A.L. chodziło, jak mniemam o sens twojego zdania - teraz lekko 
> doprecyzowałeś. (nadal dziwnie, ale już chyba wiem o co Ci chodzi (ale 
> nie wierzę ...bo to kuriozalny argument) )
> Lepiej pokaż konkretnie (kod).

Oj przestań, nawet mnie nie próbuj zanudzać stwierdzeniami, że w Javie się "po
prostu piszę inaczej", że powinienem zmienić mój sposób myślenia i stosować
inne techniki, bo się rozpłaczę do rozpuku. To samo słyszę nt. każdego
narzekania na właściwości Javy i to narzekania nie tylko takich gołodziobów
jak ja, którzy jedynie "stosują jak muszą", ale prawdziwych praktyków, którzy
na z niejednego pieca projektach zęby zjedli.

> >>>- nie dostarcza zaawansowanych metod generycznych (te Javowe generyki to jest
> >>>  jeden wielki pic na wod?; zwyk?y lukier sk?adniowy)
> > 
> > 
> >>Niby dlaczego?..
> > 
> > 
> > Sprawdź sobie pan boost::mpl (co ja mówię! Głupie STL!), to się dowiesz.

> znajdzie zapewne tak piękne fragmenty jak:
> > #include <boost/mpl/aux_/config/msvc.hpp>
> > #include <boost/mpl/aux_/config/workaround.hpp>

Ty sobie lepiej zajrzyj do implementacji Swings. Bo to, co pokazałeś niżej, to
jest tylko workaround na badziewny kompilator (co nawet widać po tych dwóch
pierwszych linijkach). Gdyby to był kod pisany tylko pod kompilatory
rzeczywiście zgodne ze standardem, nie byłoby żadnych makr. Zresztą, niech
dzisiaj będzie dzień dziecka:

Po pierwsze, to ja mimo wszystko wolę mieć dowolny kompilator do wyboru, niż
jedno centrum decyzyjne tworzące język i jego implementację.

Po drugie, co mnie obchodzi implementacja? Do implementacji zaglądam jak
jestem ciekawy, jak to goście wykoncypowali. Użytkownika interesuje jedynie
interfejs.

> >>>- nie pozwala stosowa? mechanizmu RAII
> > 
> > 
> >>Ze co?..
> > 
> > 
> > Widzę, że się nie przygotowałeś pan do dyskusji.
> > Google twoim przyjacielem.

> Możliwe, ze sie przygotował bo google bzdury pisze

Trzeba umieć szukać. Kiedyś chciałem znaleźć na googlach informacje o pewnym
dialekcie języka Brainfuck - Doublefuck. Niestety po wpisaniu tego hasła
wszystko co znalazł raczej nie było związane z programowaniem, nawet
ezoterycznym...

> - na temat RAII jest 
> ok. ale na temat tego jak to się trzeba męczyć w javie (używając finally 
> ... ) - to juz piękne bzdury.

Widzę właśnie, jak uważnie to przeczytałeś.

Dodanie finally w Javie było po prostu koniecznością, ale jeśli już bawimy się
w takie finally, to dodajmy finally w sposób całkowicie poza wyjątkami, po
prostu na koniec definicji metody (albo po prostu w dowolnym miejscu w
definicji metody, również wielokrotnie - będą wykonane w kolejności odwrotnej
do definicji). Gdybyśmy mogli mieć np.:

File f = new File( "nazwa.txt" );
finally { f.close(); }

to już mamy co prawda ręczne bo ręczne ale zawsze jakieś tam RAII. Natomiast
cały problem polega na tym, że w Javie RAII osiągnąć się nie da w ogóle.

> Tak w Javie nie ma RAII - są inne konstrukcje (mniej wygodne - z użyciem 
> dodatkowej klasy - wrappera, ale ponieważ potrzeba korzystania jest 
> dosyć rzadka - jest to mało uciążliwe) 

No, bardzo chętnie się dowiem, jakie to techniki w Javie są stosowane zamiast
RAII i zapewniają tą samą skuteczność zarządzania zasobami. I nie rozśmieszaj
mnie znów argumentem, że to rzadka potrzeba i nic nie szkodzi, że mało
wygodne.

> ( w końcu wszelkie biblioteki do 
> obsługi różnych zasobów są dawno popisane  )

Tak, szczególnie takich, o których twórcy owych bibliotek nie mieli szans
wiedzieć w czasie pisania.

> >>By the way, co to jest "pobieranie adresu"?...
> > 
> > 
> > Żargonowe określenie pobrania unikalnego identyfikatora obiektu w danym
> > systemie.
> > 
> > 
> >>>  zezwolenia udzielane s? wybiórczo; w tym wszystkim oczywi?cie te? brak
> >>>  przeci??ania operatorów)
> Wybiórczo?, zezwolenia w C++? O ile ktoś sie do d... nie dobierze 
> rzutując na jakiś void*.

Oj ty młody i naiwny...

Masz tu klasę:

class Value
{
public:
	int in;

private:
	int operator&() const { return 0; }
	template <class T>
	operator T&();

	template <class T>
	operator const T&() const;
};

Wiszę ci półkę, jak mi zmienną typu Value zrzutujesz na void*. Powodzenia.

> A w javie jakoś te aplety, servlety, ejb i inne inszety działają i 
> "wyoranie się z java security" nie jest takim trywialnym zagadnieniem.

Mnie średnio interesuje, jakie security muszą przejść te różne napletki i
serwetki. To ma się nijak do języka - jest to zupełnie osobna kwestia, którą
dana aplikacja musi przejść niezależnie od języka, w którym jest napisana.

> > Kiedyś ludzie mówili, że doskonale, że Java nie ma niczego takiego, jak wzorce
> > w C++. Po czym dodano generyki.

> Jasne... pewnie dlatego "Generic java" - projekt, który po prostu 
> niedawno wszedł do standardowej dystrybucji (po pewnych modyfikacjach) 
> był utworzony gdzieś około roku 1998.

Całkiem nieźle. Niedawno, czyli będzie to tak ze dwa lata temu (nie pamiętam,
od kiedy dokładnie generyki są w Javie). Nawet licząc, że stało się to po
czterech latach od momentu utworzenia i nawet licząc duży overhead formalny,
to trzeba przyznać, że goście "długo główkowali". Jak na to, co wymyślili, to
powinno im to zająć góra dwa miesiące, no, trzy powiedzmy, jeśli liczymy, że
dwa z tych miesięcy zajął formalny overhead.

Skoro jednak zajęło im to aż tyle czasu, to widzę tylko jedno racjonalne
wyjaśnienie: po prostu generyki zrobili zapaleńcy, którzy doskonale zdawali
sobie sprawę z tego, że są one potrzebne (dla każdego człowieka, który wie,
czym się różni statyczna i dynamiczna typizacja, zwłaszcza w języku
wspierającym OO, jest to co najmniej oczywiste). Ale nikt nie miał zamiaru
dodawać ich do języka; edukatorzy i piewcy woleli robić z siebie idiotów i
udowadniać na wszelkie możliwe sposoby, że wzorce są beee... Dopiero gdy się
okazało, że taktyka namawiania ludzi do "porzucenia starego sposobu myślenia"
przestaje skutkować, zwłaszcza jak się pojawiła konkurencja - postanowiono
skorzystać.

> Z drugiej strony, mimo że osobiście bardzo lubię generyki,  to. 
> zastanawiam się czy w dużych projektach ograniczenie sie do używania 
> tylko generycznych kolekcji nie byłoby dobrym rozwiązaniem.

Tak, najlepiej to w ogóle ograniczcie ilość używanych klas do biblioteki
standardowej i tak po jednej klasie na pakiet. Oczywiście że trzeba wprowadzić
takie ograniczenia, żeby sobie programiści Javy rączek nie poparzyli.

Nie wiem, jak to się dzieje, że jakoś ANI RAZU (!) nie zdarzyło mi się widzieć
w C++ jakiegoś "bardzo nieładnego" kodu, który by wykorzystywał wzorce albo
przeciążanie operatorów. Dokładnie było odwrotnie: kody używające tych
właściwości były napisane wręcz z wzorcową starannością. Natomiast najgorzej
i najniechlujniej napisany kod to był kod pisany "w stylu języka C".

Jestem przekonany, że nie jestem jedynym, ani wyjątkiem, ani ewenementem pod
tym względem. Tylko jakoś nie słyszę, żeby ktoś wyciągnął z tego jeden
najbardziej oczywisty w tej sytuacji wniosek: nie należy się obawiać
programistów używających wzorców i przeciążania operatorów. Należy się,
however, jak ognia bać programistów, którzy więcej pisali w C, niż w C++.


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