🚀 go-pugleaf

Dnia Wed, 9 Nov 2005 19:39:33 +0100, Filip Sielimowicz skrobie:
> > Co i tak nie zmienia faktu, że komplikacja języka wcale jednoznacznie nie
> > świadczy o jego jakości.
> Czyżbyś się asekurował na wypadek, gdyby współ-dyskutant jednak pokazał, że 
> C++ jest trudniejszy ? ;)))

Nie; asekuruję się na wypadek, gdyby współ-dyskutant zaczął udowadniać (w
ciapkach), że C++ jest gorszy przez stwierdzenie, że jest bardziej
skomplikowany.

> Jeśli przyjmiemy, że jedną z podstawowych rzeczy w tych językach jest 
> obiektowość,

Ja takiego założenia nie przyjmuję. Język ma dostarczać możliwości
wystarczające do rozwiązania tego problemu, przy czym oczywiście powinien
posiadać pewną formę obiektowości. Jaka to będzie forma, to już nie jest
istotne ALA język dobrze się nadaje do rozwiązania danego problemu.

> to niestety obiektowość C++ jest IMHO dużo bardziej zawiła,

Przecież jest zrobiona dokładnie tak samo jak w Javie.

Przyjrzyj się najpierw, czym się różni obiektowość Smalltalka i Javy, to wtedy
będziesz miał jasny pogląd co do tych "zawiłości".

> a w zasadzie nie 
> widzę
> zalet tej zawiłości. A chodzi mi np. o ideę dziedziczenia wielobazowego

A, o to ci chodzi. Przyznam, nie rozumiem, co to ma być za "zawiłość".

> (np.  z dopuszczeniem dziedziczenia obu klas bazowych po wspólnych
> przodkach, w szczególności po tej samej klasie abstrakcyjnej), dziedziczenie
> wirtualne itp pomysły - 

Nie no te wszystkie rzeczy to jest wyłącznie konsekwencja wprowadzania
dziedziczenia wielobazowego.

Kurde, który ja to raz już piszę... niedługo zbierze mi się na kolejną porcję
advocacy na stronce. Dziedziczenie w C++ jest wyłącznie _ficzerem_ językowym,
który w niektórych przypadkach _można_ wykorzystać do dziedziczenia w sensie
obiektowym. Dziedziczenie wielobazowe w sensie obiektowym nie ma sensu; z tym
się jak najbadziej zgodzę. Co prawda Stroustrup w swoich książkach próbuje
udowodnić, że ma, ale ja się z tym nie zgadzam.

Natomiast za pomocą dziedziczenia wielobazowego można tworzyć odpowiednie
systemy struktur i dostarczać dodatkowe właściwości do poszczególnych
struktur, które powiedzmy że czasem są rzeczywiście klasami. W prawdziwych
projektach obiektowych w C++ zazwyczaj dzieje się to właśnie w ten sposób, że
istnieje tylko jedna struktura, która jest faktycznie "klasą bazową" w sensie
obiektowym. Inne struktury mają za zadanie dostarczyć klasie odpowiednie
dodatkowe właściwości lub interfejsy. I w ten sposób można przeprowadzić
hierarchię "w sensie obiektowym" od korzenia do klasy wyjściowej. Tak jest np.
w Qt, gdzie wszystkie widżety dziedziczą po QWidget, a ten po QObject.

> których w Javie nie ma i nie widzę potrzeby, by takowe wprowadzać.

Jasne. W zamian wprowadzono inne.

> Zasada jest prosta: nie ma dziedziczenia wielobazowego, są interfejsy,

Ładnie powiedziane. Dzięki temu np. nie można tworzyć własnych typów
wartościowych, a implementując interfejs trzeba zawsze dostarczyć definicję
każdej poszczególnej metody (w C++ interfejs wygenerowany z IDL-a to struktura
bez pól i z metodami czysto-wirtualnymi). A dziedziczyć interfejsy można?
(pytam, bo nie wiem)

> wszystkie metody są wirtualne,

Dzięki czemu jeśli np. zapomnisz dać final, to możesz mieć piękne efekty
specjalne przy wołaniu metod z konstruktora.

> nie ma pojęcia "destruktor", w szczególności nie ma tej "niesymetrii"
> rozwiązania, które jest w C++: destruktor jako stojący po drugiej
> stronie barykady co konstruktor

Funkcjonalnie tak. Ale nie definicyjnie.

> działą wg. zdecydowanie innych zasad: np.  może być wirtualny lub nie.

A wiesz chociaż, dlaczego? :@

> I inne podobne smaczki, dot. np. wywoływania konstruktorów klas 
> bazowych.

Nie rozumiem. Że co, że zamiast super/base musisz użyć jawnej nazwy klasy
(oraz jawnie wołać konstruktor klasy dziedziczonej wirtualnie)?

> W javie jest jeden prosty schemat i nawet jak czasem może i toporny, to 
> jednak bardzo
> przejrzysty.

Dlaczego? Uzasadnij. Na razie to wychodzi na to, że przez brak dziedziczenia
wielobazowego.

> W javie może trochę przytłaczać liczba różnych rodzajów klas: wewnętrzne,
> statyczne, anonimowe, lokalne itp itd. Ale wg. mnie ta różnorodność na tym
> poziomie jest względnie bezpieczna - nie wprowadza poważnych zagrożeń, bo
> różnice nie powodują zmian w zachowaniu się obiektów

Pozwól, że nie uwierzę.

> (że wywołaął sięnie ta metoda, co chciałem ...)

No, szczególnie jak ktoś ją przedefiniował.

> a jedynie decydują o dostępności szerszego kontekstu i ew. czasie życie
> obiektu.

Nie widzę, żeby to było mniej skomplikowane od wielorakiego dziedziczenia.


-- 
//  _    ___         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"