🚀 go-pugleaf

Dnia Sun, 20 Nov 2005 14:24:21 +0100, Filip Sielimowicz skrobie:
> W związku z tym, że tamta dyskusja się dłuuuży pod innym zupełnie tytułem,
> kilka słów w nowym wątku. Mam nadzieje, że to odrobinę uporządkuje.
> Najpierw link na skromną definicję w wikipedii:

> http://pl.wikipedia.org/wiki/Dziedziczenie_(programowanie_obiektowe)

> (patrz ostatni punkt - "Wielokrotne dziedziczenie a interfejsy").
> Z powyższego artykułu wynika, że z punktu widzenia zjawiska
> wielodziedziczenia są to pojęcia bardzo zbliżone.
> Sprowadzajac jednak dyskusję na poziom konkretnych realizacji
> w Javie (interfejsy) i C++(wielodziedziczenie z użyciem klas czysto
> abstrakcyjnych) pojawia się pewien niuans widoczny przy dziedziczeniu
> po wspólnych przodkach. Do zobrazowania problemu weźmy (szczęśliwie bądź
> też mniej - rzecz na inną dyskusję ...):

> interface IPojazd {
>     getNazwa()
> }

> interfejs IPojazdPlywajacy extends IPojazd {
>     getWypornosc()
> }

> interface IPojazdLatajacy extends IPojazd {
>     getMaxUdzwig()
> }

> class Awionetka implements IPojazdPlywajacy, IPojazdLatajacy {
>     getNazwa() <-- ?????
>     ...
> }

> W przypadku C++ taka konstrukcja dziedziczenia klas abstrakcyjnych
> skutkuje tym, że metoda Awionetka.getNazwa() musi być implementowana
> DWA RAZY, ponieważ każdy przodek (implementowany interfejs) jest traktowany
> jako całkowicie odrębna, nowa jakość wprowadzana do klasy. Interfejsy
> nie wchodzą w żadną interakcję, nie nakładająsię na siebie.

Ech...

Spróbuj mnie umotywować jakoś, żeby nie zaczął przeklinać.

Tu już nie o to chodzi, że pleciesz niestworzone dyrdymały w ogóle nie
sprawdziwszy, na ile to się zgadza z prawdą. Chodzi o to, że pleciesz je mimo
tego, że ja już kiedyś całkiem niedawno WŁAŚNIE NA TEJ GRUPIE wyjaśniałem, że
w C++ wcale tak nie jest.

Żeby nie było wątpliwości, odtworzyłem twoją hierarchię, przedstawioną wyżej,
w C++; masz, weź sobie to skopiuj, skompiluj i odpal. A potem wyślij grzecznie
list z przeprosinami.

#include <iostream>
#include <string>

using namespace std;

struct IPojazd
{
	virtual string getNazwa() = 0;
	virtual ~IPojazd() {}
};

struct IPojazdPlywajacy: IPojazd
{
	virtual double getWypornosc() = 0;
};

struct IPojazdLatajacy: IPojazd
{
	virtual double getMaxUdzwig() = 0;
};

struct Awionetka: IPojazdPlywajacy, IPojazdLatajacy
{
	string getNazwa() { return "Awionetka"; }
	double getWypornosc() { return 9.76; }
	double getMaxUdzwig() { return 774.52; }
};

int main( int argc, char** argv )
{
	Awionetka* aw = new Awionetka;
	IPojazdLatajacy* lat = aw;
	IPojazdPlywajacy* plyw = aw;

	cout << plyw->getNazwa() << endl;
	cout << lat->getNazwa() << endl;

	delete aw;
	return 0;
}


> Jest to dość istotna różnica, aczkolwiek można się sprzeczać np. które
> podejście jest "bardziej intuicyjne", "właściwsze", a które 
> "bezpieczniejsze".

No to już widzisz teraz, które jest bardziej intuicyjne, właściwsze,
bezpieczniejsze i w ogóle fajniejsze i lepsze.

> Zgodnie z definicją interfejsów "właściwsze" a takze IMHO bardziej 
> intuicyjne
> jest to, co oferuje Java, natomiast bezpieczniejsze jest to, co oferuje C++,
> tym bardziej, że ta odmiennosćć jest łatwa do "obejścia" prostymi 
> konstrukcjami
> programistycznymi (delegacja wywołań).

Tym bardziej, że oba języki oferują to samo (w tej kwestii).

> Nie da się jednak rzetelnie porównać idei interfejsu z ideą klasy
> abstrakcyjnej porównując jedynie niskopoziomowe realizacje tych konstrukcji
> w różnych językach. Różnice powiem są ideowe, koncepcyjne i dotyczą np.
> kontekstu użycia jednych i drugich, sposobu projektowania aplikacji z 
> użyciem
> jednych i drugich.

Przestań bełkotać i zacznij mówić coś konkretnego. Na razie tylko potwierdzasz
tezę, że jeśli ktoś chce udowodnić że ma rację i czuje, że mu się to raczej
nie uda, to trzeba dobierać takie słowa, żeby rozmówca poczuł się jak idiota.

Oj, Brunner...

> Interfejs - zgdnie z samą nazwą - jest interfejsem, czyli
> czystą definicją "czegoś", szablonem, definicją protokołu komunikacyjnego,
> widokiem na COŚ, niekoniecznie na INSTANCJĘ KONKRETNEJ KLASY. To ostatnie
> chciałbym wyraźnie podkreślić.

Dopsze. Niech i tak będzie, ale jeśli rozważamy interfejs w kontekście
obiektowym, bo tylko w takim możemy rozważać porównanie go z klasą
abstrakcyjną, to skupmy się na interfejsie, którego intencją jest definiować
metody dostępne dla klasy, która ten interfejs implementuje.

> W Javie interfejsami można się posługiwać nie tworząc żadnych klas, które by
> je implementowały.

O, to już jest bardzo ciekawe.

> Można dynamicznie
> tworzyć obiekty rzutowalne na dowolne interfejsy bez jawnego deklarowania
> i definiowania klas implementujacych te interfejsy (obiekty te są 
> instancjami
> nieokreślonych klas, czyli patrząc z odpowiedniej wysokości - nie są 
> instancjami
> klas, w Javie nazywa sieje "dynamic proxy class").

Taaa... trochę wypasionej technologii i jeszcze wypasieńszego słownictwa i
można już zacząć mówić, że niby mamy interfejs i rzutujemy na ten interfejs,
ale klasa obiektu, który nas interesuje nie implemetuje tego interfejsu. Tzn.
niby implementuje (kurwa, pewnie że implementuje, bo inaczej byś nie
zrzutował!), ale nie ma definicji tej klasy. Tzn. niby jest (kurwa, pewnie że
jest, bo gdyby nie było klasy, to by nie było i obiektu), ale jej nie widać.
Tzn. niby widać (kurwa, nie będę kończył, bo i tak wiadomo o co chodzi)...

> Określając na sztywno interfejs, który stanowi wspólny protokół komunikacji
> między jakimiś elementami (funkcjami) systemu możemy sobie bardzo daleko
> pofantazjować w jaki sposób dany interfejs zrealizujemy, w jaki sposób
> dostarczymy do obiektu za nim ukrytego wszystkie zadeklarowane własności.
> Szczególy techniczne:
> http://java.sun.com/j2se/1.3/docs/guide/reflection/proxy.html

Nie wątpię, że właściwości jakie dano klasom w Javie znacznie wykraczają ponad
to, co dano klasom w C++.

Ale to naprawdę NIE MA NIC DO RZECZY. Jestem w stanie sobie wyobrazić
bibliotekę, która z klasami robi takie obroty, co Java. Zresztą próbował to
robić COM i ATL. Rzutowanie na konkretny interfejs odbywało się poprzez
sprawdzenie m.in. UUID-ów interfejsu, który został zapisany w danych obiektu,
przy czym oczywiście obiekt charakterystyczny klasy wyglądał już zupełnie
inaczej, niż w zwykłym C++-owym obiekcie klasy polimorficznej. Zupełnie
inaczej wyglądała też składnia, choć odpowiedni lukier składniowy dało się
dorobić (to, czego moim zdaniem w tym lukrze, typu CComPtr, brakowało, to
powiązanie interfejsu z UUID-em tak, żeby nie trzeba było podawać jednego i
drugiego razem jawnie).

Oczywiście realizacja interfejsów w czymś takim była "standardowa", czyli
interfejs to klasa czysto abstrakcyjna.

> Ta cecha już bardzo istotnie wykracza poza standardową definicję klasy i
> przekłada się to bezpośrednio na sprawy niskopoziomowe: w C++ nie jest
> wbudowany żaden mechanizm wspierajacy podobne użycie klas abstrakcyjnych
> (czyli nie ma możliwości "dynamicznej implementacji metod").

To nie jest żadna dynamiczna implementacja metod. Dynamiczna implementacja
metod polega na możliwości podmiany metody w trakcie działania programu. A to,
o czym pisałeś tutaj, to może być co najwyżej "dynamic dispatch".

> Podsumowując: z punktu widzenia C++ być może, abu zrozumieć interfejsy,
> dobrze jest je porównać do klas czysto abstrajcyjnych. Natomiast punkt
> widzenia Javy jest inny.

To wszystko to jest jeden wielki bełkot. Pozwolisz, że wypowiedź nt. tego,
czego może się programista Javy spodziewać w C++, wytnę, bo jeszcze parę
takich wypowiedzi i chyba mnie trafi.

Dyskutowaliśmy nt. tego, czy interfejsem może być klasa czysto abstrakcyjna.
To była dyskusja czysto teoretyczna i odpowiedź tak samo powinna nadejść w
kategoriach abstrakcji. Rzecz jasna bez konkretnych przykładów rozmawiać się
nie da, ale przykłady mają naprowadzać na właściwe rozwiązanie, a nie je
uzasadniać. Jeśli je uzasadniają, to znaczy że rozwiązanie nie mieści się w
granicach abstrakcji i jest zasadne tylko dla konkretnego specyficznego
przykładu. Do ogólnego twierdzenia to ma się wszakoż nijak: każdy sobie w
każdym konkretnym języku może nazwać klasą, obiektem, czy interfejsem, co też
mu się żywnie podoba, a zasady, jakimi się rządzą owe pojęcia i tak będą dla
tych języków w najlepszym razie pod kątem 30 stopni.

Na uzasadnienie, dlaczego dylemat, czy interfejsem może być klasa czysto
abstrakcyjna, jest zasadny, przytaczasz sposób realizacji interfejsów w C++.
Na dowód, dlaczego tak być nie może, przytaczasz właściwości dynamicznego
rzutowania obiektów w oparciu o interfejsy, dostępnego w Javie. De facto w
dupie masz, co te pojęcia w rzeczywistości oznaczają i jakie posiadają
właściwości i zależności; interesuje cię tylko sposób ich realizacji w
konkretnym języku programowania. No oczywiście, że jeśli za definicję
interfejsu uważasz to, co się interfejsem nazywa w Javie, to jesteś w stanie
na podobnej zasadzie udowodnić dowolną głupotę.

A żeby to wszystko było jeszcze bardziej śmieszne, to na samym początku
zastrzegasz, że interfejs niekoniecznie musi być pojęciem z dziedziny
obiektowości. Po czym uzasadniasz to dynamicznym rzutowaniem w Javie. Mniej
więcej tak, jakbyś na końcu zapomniał, o czym mówiłeś na początku.

Tymczasem dylemat, czy interfejsem może być klasa czysto abstrakcyjna dotyczy
zupełnie innych kategorii i kontekstów.

Po pierwsze, jeśli już bierzemy pod uwagę dziedzinę wtórnej obiektowości, to
jak najbardziej interfejs i klasa są pojęciami różniącymi się od siebie. Ale w
zasadzie na tym stwierdzeniu cała sprawa się kończy.

Różnica jednak bierze się nie z faktu, że różnią się one sposobem realizacji,
tylko stąd, że różnią się one intencjami, dla których zostały one stworzone.

To prawda, że klasy abstrakcyjne nie mogą i tak tworzyć obiektów i nadają się
tylko do tego, by tworzyć inne klasy. W takim podejściu nie określa się
szczególności klasy czysto abstrakcyjnej jako szczególnego przypadku klasy
abstrakcyjnej, dopóki ktoś nie wpadnie na pomysł, że z tej szczególności można
w jakiś sposób skorzystać. Dopóki jednak mówimy o klasie, to nie mamy na myśli
nic innego, jak pojęcie uczestniczące w hierarchii, tworzące inne klasy oraz
obiekty będące ich instancjami.

Jest tutaj tylko jeden problem polegający na tym, że zasadniczo wielorakie
dziedziczenie jest niemożliwe. Hierarchia klas powinna dawać odpowiedź na
pytanie, kto jest czyim przodkiem oraz czy obiekt jest instancją danej klasy.
Jeśli mamy klasy, powiedzmy, Stream i dziedziczący po nim File, to w takim
razie obiekt otworzony przez klasę File jest instancją klasy File oraz klasy
Stream. Ale jeśli zachodzi taka sytuacja, że obiekt jest instancją dwóch
oddzielnych klas, to w takim razie jedna musi być przodkiem drugiej
(niekoniecznie bezpośrednim). Taka jest zasada, której musi podlegać klasa,
biorąc pod uwagę, że dziedziczenie jest specjalizowaniem właściwości klasy.
Gdybyśmy zatem dopuścili wielorakie dziedziczenie, mogłaby powstać sytuacja,
że dwie klasy, których instancją jest określony obiekt, to są "siblings",
czyli zostaje złamana zasada, że jeden jest przodkiem drugiej.

I to jest właśnie najważniejszy powód, dla którego klasa czysto abstrakcyjna w
pojęciu czysto obiektowym interfejsem być nie może.

Po drugie, dylemat dotyczył głównie języka C++, ale w ogólności dotyczył
języków, w którym istnieje wielorakie dziedziczenie. I tutaj mamy taką właśnie
sytuację:

Ponieważ wielorakie dziedziczenie jest sprzeczne z obiektowością, więc jeśli
język dostarcza wielorakie dziedziczenie, to efektywnie pojęcie klasy jest w
tym języku jedynie REALIZOWANE za pomocą odpowiedniej konstrukcji językowej,
być może zwanej klasą. Inaczej mówiąc, jeśli stosujemy jednokrotne
dziedziczenie, to realizujemy pojęcie hierarchię klas. Jeśli stosujemy
dziedziczenie wielorakie, to nie realizujemy pojęcia hierarchii klas. Proste.

Jeśli język zaś nie dostarcza nam mechanizmu jawnie zwanego interfejsami, ale
dostarcza nam mechanizm mniej-więcej klas (w tym klas czysto abstrakcyjnych)
wraz z wielorakim dziedziczeniem, to możemy realizować zarówno klasy jak i
interfejsy w oparciu o te mechanizmy. I to wszystko.


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

On Sun, 20 Nov 2005 14:24:21 +0100, "Filip Sielimowicz"
<sielim@poczta.onet.pl> wrote:
> W Javie interfejsami można się posługiwać
>nie tworząc żadnych klas, które by je implementowały. Można dynamicznie
>tworzyć obiekty rzutowalne na dowolne interfejsy bez jawnego deklarowania
>i definiowania klas implementujacych te interfejsy...


Mozna prosic przyklad. W Javie. Od A do Z. Bo ja tego nie rozumiem.

Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. Ktos te
funkcjonalnosc musi gdeis i jakos zaimplementwoac. Wiec co to
znaczy, cytuje: "W Javie interfejsami można się posługiwać nie
tworząc żadnych klas, które by je implementowały...", konec cytatu.
To ci sie dzieje jak metode zdefiniowana w interfejcie chcemy
wywolac a nikt jej nie implementuje? Odsylamy do Swietego
Mikolaja?... A moze klucz lezy w slowie "poslugiwac sie"?...

A.L.

A.L. <alewando@kapturek62.com> napisał(a): 

> On Sun, 20 Nov 2005 14:24:21 +0100, "Filip Sielimowicz"
> <sielim@poczta.onet.pl> wrote:
> > W Javie interfejsami można się posługiwać
> >nie tworząc żadnych klas, które by je implementowały. Można dynamicznie
> >tworzyć obiekty rzutowalne na dowolne interfejsy bez jawnego deklarowania
> >i definiowania klas implementujacych te interfejsy...
> 
> 
> Mozna prosic przyklad. W Javie. Od A do Z. Bo ja tego nie rozumiem.
> 
> Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. Ktos te
> funkcjonalnosc musi gdeis i jakos zaimplementwoac. Wiec co to
> znaczy, cytuje: "W Javie interfejsami można się posługiwać nie
> tworząc żadnych klas, które by je implementowały...", konec cytatu.
> To ci sie dzieje jak metode zdefiniowana w interfejcie chcemy
> wywolac a nikt jej nie implementuje? Odsylamy do Swietego
> Mikolaja?... A moze klucz lezy w slowie "poslugiwac sie"?...

Oj oj.
To bardzo proste Java jest juz jezykiem XXII wieku kiedy to programista bedzie 
mial komputer sprzezony z mozgiem i jak tylko o czyms pomysli to wtedy 
implementacja interfejsu zosatnie dostarczone przez komputer i tyle. :D


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

tomasz sobkowiak wrote (tak! stara dobra wrotka!):

> "W Javie interfejsami można się posługiwać nie
>> tworząc żadnych klas, które by je implementowały..."

Bez jawnego definiowania tych klas, a to jest różnica. Zdaje się ze jest
możliwość w tym języku dynamicznego bindowania klas do interfejsów i myślę
że o to Filipowi tu chodziło.
Przykładu nie pokażę niestety, bo ja tego nie robiłem sam, a i nie bardzo
pamiętam przy okazji czego się z tym spotkałem. Strzelam że coś przy okazji
RMI albo class loaderów. A może to było udawanie duck typing w javie? Nie
pamiętam.

-- 
Zbigniew Malec Ustronie:104 gg:2756100

Użytkownik "A.L." <alewando@kapturek62.com> napisał w wiadomości
news:64d1o1piv0eqv05hnb0dkb58hcgui2qpuh@4ax.com...
> On Sun, 20 Nov 2005 14:24:21 +0100, "Filip Sielimowicz"
> <sielim@poczta.onet.pl> wrote:
> > W Javie interfejsami można się posługiwać
> >nie tworząc żadnych klas, które by je implementowały. Można dynamicznie
> >tworzyć obiekty rzutowalne na dowolne interfejsy bez jawnego deklarowania
> >i definiowania klas implementujacych te interfejsy...
>
>
> Mozna prosic przyklad. W Javie. Od A do Z. Bo ja tego nie rozumiem.
>
> Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. Ktos te
> funkcjonalnosc musi gdeis i jakos zaimplementwoac. Wiec co to
> znaczy, cytuje: "W Javie interfejsami można się posługiwać nie
> tworząc żadnych klas, które by je implementowały...", konec cytatu.
> To ci sie dzieje jak metode zdefiniowana w interfejcie chcemy
> wywolac a nikt jej nie implementuje? Odsylamy do Swietego
> Mikolaja?... A moze klucz lezy w slowie "poslugiwac sie"?...

No więc odesłanie do Świetego Mikołaja jest dość bliskie prawdy.
W praktyce wygląda to tak, że dostarczamy nie tyle implementację
samej metody co funkcję interpretującą (handler) same wywołania
i decydującą co z nimi zrobić.

Tworząc obiekt proxy dostarczamy więc dwie rzeczy:
1. Listę interfejsów (do każdego z nich będzie rzutowalny)
2. Handler (Swięty Mikołaj z dużym workiem) odbierający
wszelkie odwołania do metod interfejsów - instancja klasy
implementującej java.lang.reflect.InvocationHandler. Handler
ten implementuje metodę invoke(...) w parametrach której otrzymuje
dokładny identyfikator metody (w javie jest to po prostu obiekt
klasy Method) i parametry, z jakimi była wywołana, sam zaś powinien
zdefiniować parametry wyjściowe (jeśli metoda była funkcją).

Tak więc implementację wszystkich metod interfejsów zastępuje
implementacja jednego handlera.

W tym sensie, z projektowego punktu widzenia, nie ma żadnych
klas implementujących interfejsy - bo klasa handlera ich
de facto nie implementuje, a to, co sobie robi JVM wewnętrznie
to już nas nie interesuje. Jedna klasa handlera może
obsługiwać nieskończone wariacje różnych interface'ów.
Teoretycznie cały system można zbudować bez definiowania klas,
dając same interfejsy i klasę handlera, która będzie wiedziała,
co z nimi robić. Np. będzie rozpoznawała wszelkie metody
rozpoczynające się w nazwie od "set"/"get" do realizowania
zapisu/odczytu własności obiektów funkcjonujących zgodnie
ze wzorcem TransferObject.

W praktyce, od strony niskopoziomowej, oznacza to, że przy
tworzeniu obiektu proxy zamiast instancji konkretnej klasy
implementujacej podane interfejsy zazwyczaj powstaje instancja
handlera (utworzona przez użytkownika) odpowiednio obudowana
przez JVM.

To, co wyżej widać to jest pewien początek. Bo majac
taki mechanizm możemy łatwo dynamicznie uzupełniać
obiekty implementujące dowolne interfejsy o kolejne interfejsy.
Dopóki posługujemy się samymi interfejsami i nie używamy
pojęcia klasy przy zaglądaniu do obiektów, doputy taka operacja
jest względnie bezpieczna - z tym zastrzeżeniem, że po drodze
zmienia się nam referencja, a więc mogą być kłopoty z
tożsamością obiektów, jeśli sami tego nie zapewnimy
w inny sposób.

BTW. Przykład w Javie od A do Z jest w linku, który podałem.

Filip Sielimowicz <sielim@poczta.onet.pl> napisał(a): 

[ciach]

> Tak więc implementację wszystkich metod interfejsów zastępuje
> implementacja jednego handlera.

[ciach raz jeszcze]

Przepraszam, ale to pomysly z serii "bezsensowna mastrubacja". A programista 
zaczynajacy cos takiego uprawiac w komercyjnym projekcie powinien dostac za 
to po lapkach. 


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Aleksander Galicki wrote:

> Przepraszam, ale to pomysly z serii "bezsensowna mastrubacja". A programista 
> zaczynajacy cos takiego uprawiac w komercyjnym projekcie powinien dostac za 
> to po lapkach. 

Znaczy sam mechanizm dynamic proxy moze byc uzyteczny (choc oczywiscie 
nie poprzez zastepowanie normalnej implementacji). Dzieki dynamic proxy 
mozna stosowac techniki znane z AOP, co czasem jest uzyteczne.

-- 

a1 (Bartek Janusz) mailto: arcone1 [at] invalid.gmail [dot] com

Filip Sielimowicz wrote:

> W praktyce, od strony niskopoziomowej, oznacza to, że przy
> tworzeniu obiektu proxy zamiast instancji konkretnej klasy
> implementujacej podane interfejsy zazwyczaj powstaje instancja
> handlera (utworzona przez użytkownika) odpowiednio obudowana
> przez JVM.

W praktyce od strony niskopoziomowej :), wyglada to tak ze generowana 
jest klasa ktora implementuje wszystkie zadane interfejsy w ten sposob 
ze wywolanie metody na instancji tej wygenerowanej klasy powoduje 
wywolanie invoke w invocation handlerze.

-- 

a1 (Bartek Janusz) mailto: arcone1 [at] invalid.gmail [dot] com

Użytkownik "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> napisał w
wiadomości news:dlqam1$711$1@kujawiak.man.lodz.pl...

> Ech...
>
> Spróbuj mnie umotywować jakoś, żeby nie zaczął przeklinać.
>
> Tu już nie o to chodzi, że pleciesz niestworzone dyrdymały w ogóle nie
> sprawdziwszy, na ile to się zgadza z prawdą. Chodzi o to, że pleciesz je mimo
> tego, że ja już kiedyś całkiem niedawno WŁAŚNIE NA TEJ GRUPIE wyjaśniałem, że
> w C++ wcale tak nie jest.

No to przeoczyłem. Oczekiwałbym, że wyjaśnienie będzie jako odpowiedź na posta:
http://niusy.onet.pl/niusy.html?t=artykul&group=pl.comp.objects&aid=38040519
ty zaś odpowiedziałeś dosłownie posta niżej:
http://niusy.onet.pl/niusy.html?t=artykul&group=pl.comp.objects&aid=38041746
,a tego, co wyżej napisałem nie skomentowałeś. Uznałem, że mi się nie pomyliło.

> Żeby nie było wątpliwości, odtworzyłem twoją hierarchię, przedstawioną wyżej,
> w C++; masz, weź sobie to skopiuj, skompiluj i odpal. A potem wyślij grzecznie
> list z przeprosinami.

OKI. Nie spieram się. Nie będę sprawdzał, bo musiałbym się nagrzebać, ufam Ci na
słowo ;). Przepraszam, jeśli kogoś wprowadziłem w błąd.
Mogę też Ciebie przeprosić osobiście za wyrządzenie szkody na zdrowiu, ale
... to chyba jednak już nie moja wina, że tak osobiście do tematu podchodzisz ... ;)

Powiem, skąd pomyłka: kiedyś, kiedy jeszcze robiłem sporo w C++ (może się
od tego czasu coś zmieniło, cholera wi ...) miałem taki problem: załóżmy, że
w naszym przykładzie klasa IPojazd nie jest abstrakcyjna - mamy już jakąś
gotową implementację getNazwa(). Próba użycia tej metody z poziomu jakiejkolwiek
innej metody w klasie Awionetka powodowała wystąpienie błędu kompilacji: kompilator
domagał się, by określić, czy odwołujemy się do metody z klasy bazowej
IPojazdPlywajacy, czy IPojazdLatajacy - mimo, że implementacja była
jedna i ta sama w klasie bazowej IPojazd.
Inaczej: sytuacja ta występowała, kiedy na skutek wielodziedziczenia
hierarchia przodków klasy stanowiła kratę a nie drzewo. Być może
problem ten dotyczył metod niewirtualnych, a ja tego nie pamiętam,
a może nie ... Nie wiem teraz. tak wyglądało to w praktyce, a ja najpewniej
niesłusznie wyciągnąłem z tego za daleko posunięte wnioski.

> > Można dynamicznie
> > tworzyć obiekty rzutowalne na dowolne interfejsy bez jawnego deklarowania
> > i definiowania klas implementujacych te interfejsy (obiekty te są
> > instancjami
> > nieokreślonych klas, czyli patrząc z odpowiedniej wysokości - nie są
> > instancjami
> > klas, w Javie nazywa sieje "dynamic proxy class").
>
> Taaa... trochę wypasionej technologii i jeszcze wypasieńszego słownictwa i
> można już zacząć mówić, że niby mamy interfejs i rzutujemy na ten interfejs,
> ale klasa obiektu, który nas interesuje nie implemetuje tego interfejsu. Tzn.
> niby implementuje (kurwa, pewnie że implementuje, bo inaczej byś nie
> zrzutował!), ale nie ma definicji tej klasy. Tzn. niby jest (kurwa, pewnie że
> jest, bo gdyby nie było klasy, to by nie było i obiektu), ale jej nie widać.
> Tzn. niby widać (kurwa, nie będę kończył, bo i tak wiadomo o co chodzi)...

No niestety ;). Wyjaśniłem dokładnie jak to chodzi.
Oczywiście, sama maszyna wirtualna, a pewnie dokładniej schowany w niej JIT
widzi i jedno i drugie bardzo podobnie - co ma sobie życie utrudniać. Ale
ja nie nazwałbym tego "klasą".

Jedno jest pewne - jak poczytasz o tym, to zauważysz, że jest jak mówię:
programista klas na oczy nie widzi. Widzi tylko interfejsy. A projektant
nie dość, że klas nie widzi, to nawet o nich nie myśli.
I tu jest właśnie pies pogrzebany.

No nie ma klas, pane, nie ma. Są interfejsy, są obiekty, są zasady ich przetwarzania
- stworzone na potrzeby projektu - ale klas nie widać ... Jak się uprzesz - to
zobaczysz tę klasę ( o.getClass() ). Ale jej definicji już w swoim projekcie nie
uświadczysz.

> Nie wątpię, że właściwości jakie dano klasom w Javie znacznie wykraczają ponad
> to, co dano klasom w C++.
>
> Ale to naprawdę NIE MA NIC DO RZECZY.
Ależ ma ;)

> Jestem w stanie sobie wyobrazić bibliotekę, która z klasami robi takie obroty,
> co Java.
Czekałem na ten argument. Wisz pane, jakie biblioteki ja sobie potrafię
w Javie wyobrazić ? Pane ... prawie mdleję, jak zaczynam ...
Są już różne ciekawe - zdaje się, że próbują np. rozszerzyć powyższe
o klasy - np. żeby obiekt konkretnej klasy można dynamicznie uzupełnić
o dowolny interfejs, a by po tej operacji obiekt ten nie utracił
informacji o tym jakiej jest klasy (standardowo informacji o klasie nie ma jak
przepchnąć).

> > Ta cecha już bardzo istotnie wykracza poza standardową definicję klasy i
> > przekłada się to bezpośrednio na sprawy niskopoziomowe: w C++ nie jest
> > wbudowany żaden mechanizm wspierajacy podobne użycie klas abstrakcyjnych
> > (czyli nie ma możliwości "dynamicznej implementacji metod").
>
> To nie jest żadna dynamiczna implementacja metod. Dynamiczna implementacja
> metod polega na możliwości podmiany metody w trakcie działania programu. A to,
> o czym pisałeś tutaj, to może być co najwyżej "dynamic dispatch".

No cóż ... No dobra ... Ale nie do końca ... ;)
Pocieszę Cię tylko, że "różne biblioteki Java" potrafią w runtimie generować
bytekod - i robią to na chwałę celów, które sobie stawiają.
BTW. A widziałeś ty, jak działa debugger javy pod Eclipse ? :)
Normalnie dynamicznie podmienia kod ;). Uruchamiasz sobie programik, wywaliło
ci NullPointerExceptiona po naciśnięciu buttona na formatce, zaglądasz do kodu,
no tak - bug - poprawiasz, zapisujesz, wciskasz klawisz jeszcze raz i ... bingo ;).
Potężne środowisko uruchomieniowe z gigantyczną formatką ani drgnęło w czasie tej
operacji a kod się podmienił. I nie są to wielkie czary-mary - można to także
z pewnym wysiłkiem, realizować programowo (definicja własnego ClassLoadera).

> To wszystko to jest jeden wielki bełkot. Pozwolisz, że wypowiedź nt. tego,
> czego może się programista Javy spodziewać w C++, wytnę, bo jeszcze parę
> takich wypowiedzi i chyba mnie trafi.

Znaczy się żyłka pęknie ... Ostrzegałem ...

> Dyskutowaliśmy nt. tego, czy interfejsem może być klasa czysto abstrakcyjna.
> To była dyskusja czysto teoretyczna i odpowiedź tak samo powinna nadejść w
> kategoriach abstrakcji.

No to z teoretycznego punktu widzenia są to różne rzeczy. Kiedy powstawał C++
nie było mowy o interfejsach, powstały klasy abstrakcyjne i dziedziczenie
tychże. Sprawa jest prosta ;).

> Rzecz jasna bez konkretnych przykładów rozmawiać się
> nie da, ale przykłady mają naprowadzać na właściwe rozwiązanie, a nie je
> uzasadniać. Jeśli je uzasadniają, to znaczy że rozwiązanie nie mieści się w
> granicach abstrakcji i jest zasadne tylko dla konkretnego specyficznego
> przykładu. Do ogólnego twierdzenia to ma się wszakoż nijak: każdy sobie w
> każdym konkretnym języku może nazwać klasą, obiektem, czy interfejsem, co też
> mu się żywnie podoba, a zasady, jakimi się rządzą owe pojęcia i tak będą dla
> tych języków w najlepszym razie pod kątem 30 stopni.
E. A fe ... kto tak brzydko robi ?

> Na uzasadnienie, dlaczego dylemat, czy interfejsem może być klasa czysto
> abstrakcyjna, jest zasadny, przytaczasz sposób realizacji interfejsów w C++.
> Na dowód, dlaczego tak być nie może, przytaczasz właściwości dynamicznego
> rzutowania obiektów w oparciu o interfejsy, dostępnego w Javie. De facto w
> dupie masz, co te pojęcia w rzeczywistości oznaczają i jakie posiadają
> właściwości i zależności; interesuje cię tylko sposób ich realizacji w
> konkretnym języku programowania. No oczywiście, że jeśli za definicję
> interfejsu uważasz to, co się interfejsem nazywa w Javie, to jesteś w stanie
> na podobnej zasadzie udowodnić dowolną głupotę.
>
> A żeby to wszystko było jeszcze bardziej śmieszne, to na samym początku
> zastrzegasz, że interfejs niekoniecznie musi być pojęciem z dziedziny
> obiektowości. Po czym uzasadniasz to dynamicznym rzutowaniem w Javie. Mniej
> więcej tak, jakbyś na końcu zapomniał, o czym mówiłeś na początku.

Eee tam ... Histeria.

> Tymczasem dylemat, czy interfejsem może być klasa czysto abstrakcyjna dotyczy
> zupełnie innych kategorii i kontekstów.
>
> Po pierwsze, jeśli już bierzemy pod uwagę dziedzinę wtórnej obiektowości, to
> jak najbardziej interfejs i klasa są pojęciami różniącymi się od siebie. Ale w
> zasadzie na tym stwierdzeniu cała sprawa się kończy.
>
> Różnica jednak bierze się nie z faktu, że różnią się one sposobem realizacji,
> tylko stąd, że różnią się one intencjami, dla których zostały one stworzone.

No przesz o tym mówię.

> To prawda, że klasy abstrakcyjne nie mogą i tak tworzyć obiektów i nadają się
> tylko do tego, by tworzyć inne klasy. W takim podejściu nie określa się
> szczególności klasy czysto abstrakcyjnej jako szczególnego przypadku klasy
> abstrakcyjnej, dopóki ktoś nie wpadnie na pomysł, że z tej szczególności można
> w jakiś sposób skorzystać. Dopóki jednak mówimy o klasie, to nie mamy na myśli
> nic innego, jak pojęcie uczestniczące w hierarchii, tworzące inne klasy oraz
> obiekty będące ich instancjami.

No właśnie. A klasa obiektu proxy w javie nie spełnia tych wymagań
- bo nie uczestniczy w hierarchii, nie tworzy innych klas ... A więc może
lepiej nie nazywać jej klasą ? Ja jestem za. Proponuję uznać, że nie ma
tu klasy, a są tylko interfejsy. A interfejs klasą nie jest. Zapomniałeś
o tym, że klasy mają pola i metody - zgodnie z najbardziej pierwotnymi
założeniami OOP - dopiero potem mówimy o dziedziczeniu itp.

> Jest tutaj tylko jeden problem polegający na tym, że zasadniczo wielorakie
> dziedziczenie jest niemożliwe. Hierarchia klas powinna dawać odpowiedź na
> pytanie, kto jest czyim przodkiem oraz czy obiekt jest instancją danej klasy.
> Jeśli mamy klasy, powiedzmy, Stream i dziedziczący po nim File, to w takim
> razie obiekt otworzony przez klasę File jest instancją klasy File oraz klasy
> Stream. Ale jeśli zachodzi taka sytuacja, że obiekt jest instancją dwóch
> oddzielnych klas, to w takim razie jedna musi być przodkiem drugiej
> (niekoniecznie bezpośrednim). Taka jest zasada, której musi podlegać klasa,
> biorąc pod uwagę, że dziedziczenie jest specjalizowaniem właściwości klasy.
> Gdybyśmy zatem dopuścili wielorakie dziedziczenie, mogłaby powstać sytuacja,
> że dwie klasy, których instancją jest określony obiekt, to są "siblings",
> czyli zostaje złamana zasada, że jeden jest przodkiem drugiej.

... chyba nie za bardzo widzę związek ... ale masz rację - z tym wielodziedziczeniem
to same kłopoty ... ;) Bałagan i w ogóle ... Zamiast drzew jakiesz koszmarne
labirynty ...

> I to jest właśnie najważniejszy powód, dla którego klasa czysto abstrakcyjna w
> pojęciu czysto obiektowym interfejsem być nie może.

O. To mi się podoba ;).

> Po drugie, dylemat dotyczył głównie języka C++, ale w ogólności dotyczył
> języków, w którym istnieje wielorakie dziedziczenie. I tutaj mamy taką właśnie
> sytuację:
>
> Ponieważ wielorakie dziedziczenie jest sprzeczne z obiektowością, więc jeśli
> język dostarcza wielorakie dziedziczenie, to efektywnie pojęcie klasy jest w
> tym języku jedynie REALIZOWANE za pomocą odpowiedniej konstrukcji językowej,
> być może zwanej klasą. Inaczej mówiąc, jeśli stosujemy jednokrotne
> dziedziczenie, to realizujemy pojęcie hierarchię klas. Jeśli stosujemy
> dziedziczenie wielorakie, to nie realizujemy pojęcia hierarchii klas. Proste.
>
> Jeśli język zaś nie dostarcza nam mechanizmu jawnie zwanego interfejsami, ale
> dostarcza nam mechanizm mniej-więcej klas (w tym klas czysto abstrakcyjnych)
> wraz z wielorakim dziedziczeniem, to możemy realizować zarówno klasy jak i
> interfejsy w oparciu o te mechanizmy. I to wszystko.

Dobra ... Jeszcze nie wiem, czy jestem za, ale wiem, że jeszcze nie jestem
przeciw ... ;)

A.L. <alewando@kapturek62.com> writes:

[...]

> Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. 

Skądże znowu.  Interfejs to tylko nazwy metod i ewentualne typy.
Zapowiedź funkcjonalności to jest w specyfikacji wymagań.

Użytkownik "a1" <arcone1@gmail.com> napisał w wiadomości
news:dlqiqm$6n5$2@inews.gazeta.pl...
> Filip Sielimowicz wrote:
>
> > W praktyce, od strony niskopoziomowej, oznacza to, że przy
> > tworzeniu obiektu proxy zamiast instancji konkretnej klasy
> > implementujacej podane interfejsy zazwyczaj powstaje instancja
> > handlera (utworzona przez użytkownika) odpowiednio obudowana
> > przez JVM.
>
> W praktyce od strony niskopoziomowej :), wyglada to tak ze generowana
> jest klasa ktora implementuje wszystkie zadane interfejsy w ten sposob
> ze wywolanie metody na instancji tej wygenerowanej klasy powoduje
> wywolanie invoke w invocation handlerze.

Oczywiście ;).
Chociaż równie dobrze można powiedzieć, że generowana jest nie klasa, tylko
kawałek bytekodu podobny do tego, który jest generowany dla klasy ;).
Zależy od punktu widzenia. jeśłi przyjąć, że klasą jest coś, kto ktoś
gdzieś zaprojektował a potem zaimplementował ...

"Filip Sielimowicz" <sielim@poczta.onet.pl> writes:

[...]

> BTW. Przykład w Javie od A do Z jest w linku, który podałem.

Bardzo to fajne, tylko po co implementować funkcjonalność języka 
z dynamicznym systemem typów w języku ze statycznym systemem typów?

Taka 'nakładka' na Javę już istnieje i nazywa się Jython.  Zresztą
pewnie nie tylko Jython -- ostatnio pojawiło się wiele języków 
wysokiego poziomu współgrających z JVM.

-- 
http://www.piotr.dembiński.prv.pl

"Aleksander Galicki" <tretete@NOSPAM.gazeta.pl> writes:

[...]

> A programista zaczynajacy cos takiego uprawiac w komercyjnym 
> projekcie powinien dostac za to po lapkach.

Każdy wystarczająco skomplikowany program ma w sobie pełną błędów,
niekompletną i powolną implementację interpretera Lispa ;)

On Sun, 20 Nov 2005 20:31:43 +0100, a1 <arcone1@gmail.com> wrote:

>Filip Sielimowicz wrote:
>
>> W praktyce, od strony niskopoziomowej, oznacza to, że przy
>> tworzeniu obiektu proxy zamiast instancji konkretnej klasy
>> implementujacej podane interfejsy zazwyczaj powstaje instancja
>> handlera (utworzona przez użytkownika) odpowiednio obudowana
>> przez JVM.
>
>W praktyce od strony niskopoziomowej :), wyglada to tak ze generowana 
>jest klasa 

A....cha... To znaczy jest jakas klasa.

A.L.

On Sun, 20 Nov 2005 19:42:15 +0100, Zbyszek Malec
<zbyszekto@tlen.pl> wrote:

>tomasz sobkowiak wrote (tak! stara dobra wrotka!):
>
>> "W Javie interfejsami można się posługiwać nie
>>> tworząc żadnych klas, które by je implementowały..."
>
>Bez jawnego definiowania tych klas, a to jest różnica. Zdaje się ze jest
>możliwość w tym języku dynamicznego bindowania klas do interfejsów i myślę
>że o to Filipowi tu chodziło.

Zdaje sie?.... Jakis byl taki utwor poetcycki ktory zawieral fraze
"... wszystkim sie zdaalo... a to echo gralo..."

A.L.

P.S> Co to jest "bindowanie" i to "dynamiczne"?...

A.L. wrote (tak! stara dobra wrotka!):

> Zdaje sie?.... Jakis byl taki utwor poetcycki ktory zawieral fraze
> "... wszystkim sie zdaalo... a to echo gralo..."

Było coś jeszcze o cymbale grzmiącym o ile dobrze pamiętam. Niby autor
niekoniecznie ten sam, ale kto by wierzył historykom?

> P.S> Co to jest "bindowanie" i to "dynamiczne"?...

Co to jest czy o co mi chodzi? Jeśli to pierwsze to nie podejmuję się
definiować. Jeśli to drugie - widzę że inni napisali już to lepiej i
jaśniej, więc chyba nie ma sensu żebym ja to jeszcze raz pisał.

-- 
Zbigniew Malec Ustronie:104 gg:2756100

On Sun, 20 Nov 2005 21:36:13 +0100, Zbyszek Malec
<zbyszekto@tlen.pl> wrote:

>A.L. wrote (tak! stara dobra wrotka!):
>
>> Zdaje sie?.... Jakis byl taki utwor poetcycki ktory zawieral fraze
>> "... wszystkim sie zdaalo... a to echo gralo..."
>
>Było coś jeszcze o cymbale grzmiącym o ile dobrze pamiętam. Niby autor
>niekoniecznie ten sam, ale kto by wierzył historykom?
>
>> P.S> Co to jest "bindowanie" i to "dynamiczne"?...
>
>Co to jest czy o co mi chodzi? Jeśli to pierwsze to nie podejmuję się
>definiować. Jeśli to drugie - widzę że inni napisali już to lepiej i
>jaśniej, więc chyba nie ma sensu żebym ja to jeszcze raz pisał.

Droselklapa na szoner robiona i ryksztosuje. No i trzeba ja
zabindowac.

To cytat z Tuwima.

A.L.

Dnia Sun, 20 Nov 2005 21:01:19 +0100, Filip Sielimowicz skrobie:

> Użytkownik "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> napisał w
> wiadomo?ci news:dlqam1$711$1@kujawiak.man.lodz.pl...

> > Ech...
> >
> > Spróbuj mnie umotywować jako?, żeby nie zacz?ł przeklinać.
> >
> > Tu już nie o to chodzi, że pleciesz niestworzone dyrdymały w ogóle nie
> > sprawdziwszy, na ile to się zgadza z prawd?. Chodzi o to, że pleciesz je mimo
> > tego, że ja już kiedy? całkiem niedawno WŁA?NIE NA TEJ GRUPIE wyja?niałem, że
> > w C++ wcale tak nie jest.

> No to przeoczyłem. Oczekiwałbym, że wyja?nienie będzie jako odpowiedĽ na posta:
> http://niusy.onet.pl/niusy.html?t=artykul&group=pl.comp.objects&aid=38040519
> ty za? odpowiedziałe? dosłownie posta niżej:
> http://niusy.onet.pl/niusy.html?t=artykul&group=pl.comp.objects&aid=38041746
> ,a tego, co wyżej napisałem nie skomentowałe?. Uznałem, że mi się nie pomyliło.

Nie napisałem, bo nie miałem wtedy dostępu do środowiska, na którym mógłbym to
sprawdzić. Albo nie miałem czasu, już nie pamiętam. W każdym razie uzupełniłem
to później.

> Powiem, sk?d pomyłka: kiedy?, kiedy jeszcze robiłem sporo w C++ (może się
> od tego czasu co? zmieniło, cholera wi ...) miałem taki problem: załóżmy, że
> w naszym przykładzie klasa IPojazd nie jest abstrakcyjna - mamy już jak??
> gotow? implementację getNazwa(). Próba użycia tej metody z poziomu jakiejkolwiek
> innej metody w klasie Awionetka powodowała wyst?pienie błędu kompilacji: kompilator
> domagał się, by okre?lić, czy odwołujemy się do metody z klasy bazowej
> IPojazdPlywajacy, czy IPojazdLatajacy - mimo, że implementacja była
> jedna i ta sama w klasie bazowej IPojazd.

W C++ (pewnie w innych językach problem jest podobny) problem z wielorakim
dziedziczeniem objawia się w ten sposób, że jeśli dwie oddzielne klasy
dostarczają osobne definicje tej samej metody, to wtedy wywołanie tej metody w
klasie pochodnej jest niejednoznaczne.

Można by to wręcz w uproszczeniu określić w ten sposób, że metoda zdublowana w
klasie dziedziczonej jako "sibling" nie podlega dziedziczeniu. Rozwiązuje się
ten problem bowiem w podobny sposób: trzeba dostarczyć odpowiednią definicję
metody w klasie pochodnej i ewentualnie wywołać metody z klas bazowych jawnie.

Zresztą tu w grę wchodzi następna rzecz typowa dla obiektowości i niezbyt
sensownie możliwa do zrealizowania, gdy mamy wielorakie dziedziczenie: każda
metoda powinna mieć tzw. globalną definicję. Tzn. np. jeśli metoda nazywa się
"open" i ma otwierać plik, to w KAŻDYM istniejącym w systemie obiekcie ma
powodować otwarcie plik, niezależnie od tego, jakiej on jest klasy. Inaczej
mówiąc, nie może być w systemie dwóch metod o tej samej nazwie, których
intencją jest robienie zupełnie innych rzeczy. Np. przy takiej definicji
"open" nie może istnieć metoda "open", która "otwiera" okno.

> Oczywi?cie, sama maszyna wirtualna, a pewnie dokładniej schowany w niej JIT
> widzi i jedno i drugie bardzo podobnie - co ma sobie życie utrudniać. Ale
> ja nie nazwałbym tego "klas?".

Niby czemu?

> Jedno jest pewne - jak poczytasz o tym, to zauważysz, że jest jak mówię:
> programista klas na oczy nie widzi. Widzi tylko interfejsy.

Gówno mnie obchodzi, co widzi programista. Ważne, że klasa istnieje w
systemie.

> A projektant
> nie do?ć, że klas nie widzi, to nawet o nich nie my?li.
> I tu jest wła?nie pies pogrzebany.

A to już nie rozumiem, co ma do rzeczy.

W C++ programista tych klas też może "nie widzieć", np. przez to, że nie
ogląda plików z ich definicją.

Nie wiem, co ty właściwie tutaj chcesz pokazać jako "ficzer". Czy to, że
programista nie potrzebuje widzieć, czy to, że programista nie może widzieć?

> No nie ma klas, pane, nie ma. S? interfejsy, s? obiekty, s? zasady ich przetwarzania
> - stworzone na potrzeby projektu - ale klas nie widać ... Jak się uprzesz - to
> zobaczysz tę klasę ( o.getClass() ). Ale jej definicji już w swoim projekcie nie
> u?wiadczysz.

Ja w swoim projekcie też nie miewam klas np. ostream.

> > Nie w?tpię, że wła?ciwo?ci jakie dano klasom w Javie znacznie wykraczaj? ponad
> > to, co dano klasom w C++.
> >
> > Ale to naprawdę NIE MA NIC DO RZECZY.
> Ależ ma ;)

Nie ma. Rozmawialiśmy o ogólnym pojęciu interfejsu i klasy, a nie o tym, jakie
sztuczki można robić w Javie.

> > Jestem w stanie sobie wyobrazić bibliotekę, która z klasami robi takie obroty,
> > co Java.
> Czekałem na ten argument. Wisz pane, jakie biblioteki ja sobie potrafię
> w Javie wyobrazić ? Pane ... prawie mdleję, jak zaczynam ...

Nie mówimy o hipotetycznych bibliotekach, tylko o tych, które były
realizowane.

> S? już różne ciekawe - zdaje się, że próbuj? np. rozszerzyć powyższe
> o klasy - np. żeby obiekt konkretnej klasy można dynamicznie uzupełnić
> o dowolny interfejs, a by po tej operacji obiekt ten nie utracił
> informacji o tym jakiej jest klasy (standardowo informacji o klasie nie ma jak
> przepchn?ć).

Przecież to proste (jeśli jesteśmy w stanie podmieniać klasy). Podmieniamy po
prostu obiekt charakterystyczny klasy.

W C++ też można takie sztuczki robić. Ponieważ obiekt charakterystyczny jest
niczym innym jak obiektem, więc mając w bibliotece dynamicznej definicję
obiektu charakterystycznego klasy oraz metod tej klasy po prostu zamykamy
bibliotekę i otwieramy na nowo.

A interfejs spasujemy z obiektem i tak po UUID-zie.

> Pocieszę Cię tylko, że "różne biblioteki Java" potrafi? w runtimie generować
> bytekod - i robi? to na chwałę celów, które sobie stawiaj?.

Wiesz, biorąc pod uwagę wydajność Javy, jak miałbym się w takie rzeczy bawić,
to wykorzystałbym języki skryptowe.

> BTW. A widziałe? ty, jak działa debugger javy pod Eclipse ? :)
> Normalnie dynamicznie podmienia kod ;). Uruchamiasz sobie programik, wywaliło
> ci NullPointerExceptiona po naci?nięciu buttona na formatce, zagl?dasz do kodu,
> no tak - bug - poprawiasz, zapisujesz, wciskasz klawisz jeszcze raz i ... bingo ;).
> Potężne ?rodowisko uruchomieniowe z gigantyczn? formatk? ani drgnęło w czasie tej
> operacji a kod się podmienił. I nie s? to wielkie czary-mary - można to także
> z pewnym wysiłkiem, realizować programowo (definicja własnego ClassLoadera).

Wiesz, w Tk jeśli wystąpi ci błąd (nawet składniowy) w procedurze obsługi
jakiegoś przycisku, to dostajesz okienko z ostrzeżeniem, klikasz OK i
aplikacja dalej działa. Nie widzę również problemu, żeby podzielić skrypt na
część z implementacją (definicja handlerów) i część definicyjną (gdzie te
handlery się podpina). A potem ewentualnie spod programu wykonać "source".

Mając "klasy definiowane w bibliotece dynamicznej", mogę to samo robić też w
C++.

> > Dyskutowali?my nt. tego, czy interfejsem może być klasa czysto abstrakcyjna.
> > To była dyskusja czysto teoretyczna i odpowiedĽ tak samo powinna nadej?ć w
> > kategoriach abstrakcji.

> No to z teoretycznego punktu widzenia s? to różne rzeczy. Kiedy powstawał C++
> nie było mowy o interfejsach,

Fakt. Istniało już kilka języków obiektowych (C++ to 80-te lata) i żaden nie
miał pojęcia interfejsu (niech mnie bardziej zorientowani poprawią, oczywiście
:).

> > Rzecz jasna bez konkretnych przykładów rozmawiać się
> > nie da, ale przykłady maj? naprowadzać na wła?ciwe rozwi?zanie, a nie je
> > uzasadniać. Je?li je uzasadniaj?, to znaczy że rozwi?zanie nie mie?ci się w
> > granicach abstrakcji i jest zasadne tylko dla konkretnego specyficznego
> > przykładu. Do ogólnego twierdzenia to ma się wszakoż nijak: każdy sobie w
> > każdym konkretnym języku może nazwać klas?, obiektem, czy interfejsem, co też
> > mu się żywnie podoba, a zasady, jakimi się rz?dz? owe pojęcia i tak będ? dla
> > tych języków w najlepszym razie pod k?tem 30 stopni.
> E. A fe ... kto tak brzydko robi ?

Poza Smalltalkiem (nie wiem jak języki Lispopochodne, pewnie też) to chyba
każdy współcześnie używany język.

> > Tymczasem dylemat, czy interfejsem może być klasa czysto abstrakcyjna dotyczy
> > zupełnie innych kategorii i kontekstów.
> >
> > Po pierwsze, je?li już bierzemy pod uwagę dziedzinę wtórnej obiektowo?ci, to
> > jak najbardziej interfejs i klasa s? pojęciami różni?cymi się od siebie. Ale w
> > zasadzie na tym stwierdzeniu cała sprawa się kończy.
> >
> > Różnica jednak bierze się nie z faktu, że różni? się one sposobem realizacji,
> > tylko st?d, że różni? się one intencjami, dla których zostały one stworzone.

> No przesz o tym mówię.

No właśnie. Tyle że ich konstrukcja może być identyczna, niezależnie od tych
intencji. O tym już nie pomyślałeś?

> > To prawda, że klasy abstrakcyjne nie mog? i tak tworzyć obiektów i nadaj? się
> > tylko do tego, by tworzyć inne klasy. W takim podej?ciu nie okre?la się
> > szczególno?ci klasy czysto abstrakcyjnej jako szczególnego przypadku klasy
> > abstrakcyjnej, dopóki kto? nie wpadnie na pomysł, że z tej szczególno?ci można
> > w jaki? sposób skorzystać. Dopóki jednak mówimy o klasie, to nie mamy na my?li
> > nic innego, jak pojęcie uczestnicz?ce w hierarchii, tworz?ce inne klasy oraz
> > obiekty będ?ce ich instancjami.

> No wła?nie. A klasa obiektu proxy w javie nie spełnia tych wymagań
> - bo nie uczestniczy w hierarchii, nie tworzy innych klas ...

Jeśli tworzy obiekty, to jest klasą.
Z tą hierarchią to byłbym na twoim miejscu ostrożniejszy; podobno każda klasa
w Javie niejawnie dziedziczy po Object.

> A więc może
> lepiej nie nazywać jej klas? ? Ja jestem za. Proponuję uznać, że nie ma
> tu klasy, a s? tylko interfejsy. A interfejs klas? nie jest. Zapomniałe?
> o tym, że klasy maj? pola i metody

Klasy nie muszą mieć ani pól, ani metod, żeby być klasą. Tzn. z metodami to
nie jest tak jednoznacznie, ale pola nie są obowiązkowe. Klasy czysto
abstrakcyjne mogą mieć pola tylko teoretycznie (po cholere im pola, skoro nie
definiują niczego, co na nich operuje?).

> - zgodnie z najbardziej pierwotnymi założeniami OOP -

Klasa jest pojęciem wtórnym w obiektowości, więc nie bardzo pierwotnymi.

> dopiero potem mówimy o dziedziczeniu itp.

O dziedziczeniu mówimy przede wszystkim, jeśli mówimy o klasach.

> > Ponieważ wielorakie dziedziczenie jest sprzeczne z obiektowo?ci?, więc je?li
> > język dostarcza wielorakie dziedziczenie, to efektywnie pojęcie klasy jest w
> > tym języku jedynie REALIZOWANE za pomoc? odpowiedniej konstrukcji językowej,
> > być może zwanej klas?. Inaczej mówi?c, je?li stosujemy jednokrotne
> > dziedziczenie, to realizujemy pojęcie hierarchię klas. Je?li stosujemy
> > dziedziczenie wielorakie, to nie realizujemy pojęcia hierarchii klas. Proste.
> >
> > Je?li język za? nie dostarcza nam mechanizmu jawnie zwanego interfejsami, ale
> > dostarcza nam mechanizm mniej-więcej klas (w tym klas czysto abstrakcyjnych)
> > wraz z wielorakim dziedziczeniem, to możemy realizować zarówno klasy jak i
> > interfejsy w oparciu o te mechanizmy. I to wszystko.

> Dobra ... Jeszcze nie wiem, czy jestem za, ale wiem, że jeszcze nie jestem
> przeciw ... ;)

Aha, to oczywiście nie do końca wszystko.

Jeśli w danym języku interfejs zostanie zrealizowany za pomocą klasy czysto
abstrakcyjnej, to powstaje twór, który może pełnić rolę interfejsu i klasy
równocześnie.

Zgadzam się zatem ze stwierdzeniem "Interfejs nie jest klasą", jeśli mamy na
myśli intencje nadawane tym tworom.

Nie zgadzam się natomiast, że w sensie konstrukcji w jakimś języku
programowania nie może być klasy będącej przypadkiem równocześnie interfejsem.
Jeśli tak się zdarzy, to wtedy interfejs jest klasą (choć jest klasą tylko
czysto abstrakcyjną, co w praktyce oznacza obcięcie funkcjonalności takiej
klasy do minimum).


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

Dnia Sun, 20 Nov 2005 21:04:35 +0100, Piotr Dembiński skrobie:
> A.L. <alewando@kapturek62.com> writes:

> [...]

> > Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. 

> Skądże znowu.  Interfejs to tylko nazwy metod i ewentualne typy.

Po pierwsze, nie "nazwy metod", tylko sygnatury metod. A to diametralna
różnica.

Po drugie, typy są już specjalnością języków o statycznej typizacji.

> Zapowiedź funkcjonalności to jest w specyfikacji wymagań.

Zapowiedź funkcjonalności OBIEKTU w SPECYFIKACJI WYMAGAŃ???

To jest chyba bajka z innego świata. Nie widziałem jeszcze klienta, który by
dyktował połowę kodu.

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

> Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. Ktos te
> funkcjonalnosc musi gdeis i jakos zaimplementwoac. Wiec co to
> znaczy, cytuje: "W Javie interfejsami można się posługiwać nie
> tworząc żadnych klas, które by je implementowały...", konec cytatu.
> To ci sie dzieje jak metode zdefiniowana w interfejcie chcemy
> wywolac a nikt jej nie implementuje? Odsylamy do Swietego
> Mikolaja?... A moze klucz lezy w slowie "poslugiwac sie"?...

Dla porządku:
istnieje coś takiego jak marker interface - brak deklaracji metod (i pól), 
nadaje klasie jakąś cechę.
Przykład takiego interfejsu: java.io.Serializable.

PL 

Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> Dnia Sun, 20 Nov 2005 21:04:35 +0100, Piotr Dembiński skrobie:
>> A.L. <alewando@kapturek62.com> writes:
>
>> [...]
>
>> > Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. 
>
>> Skądże znowu.  Interfejs to tylko nazwy metod i ewentualne typy.
>
> Po pierwsze, nie "nazwy metod", tylko sygnatury metod. 
> A to diametralna różnica.

OK, niech będzie 'sygnatury'.

> Po drugie, typy są już specjalnością języków o statycznej typizacji.

Dlatego napisałem 'ewentualne'.

>> Zapowiedź funkcjonalności to jest w specyfikacji wymagań.
>
> Zapowiedź funkcjonalności OBIEKTU w SPECYFIKACJI WYMAGAŃ???

A czym jest program, jak nie obiektem?  A raczej: uruchomiony program,
czyli proces systemu operacyjnego jest obiektem, a sam program jest
definicją typu tego obiektu.

> To jest chyba bajka z innego świata. Nie widziałem jeszcze klienta,
> który by dyktował połowę kodu.

A ja nie widziałem jeszcze klienta, który by pozostawił zdefiniowanie
funkcjonalności programu programistom :)

-- 
http://www.piotr.dembiński.prv.pl

Dnia Mon, 21 Nov 2005 12:49:14 +0100, Piotr Dembiński skrobie:
> >> Zapowiedź funkcjonalności to jest w specyfikacji wymagań.
> >
> > Zapowiedź funkcjonalności OBIEKTU w SPECYFIKACJI WYMAGAŃ???

> A czym jest program, jak nie obiektem?  A raczej: uruchomiony program,
> czyli proces systemu operacyjnego jest obiektem, a sam program jest
> definicją typu tego obiektu.

O, to bardzo ciekawe podejście. I pewnie ten obiekt ma jeszcze dodatkowo
jakieś określone interfejsy?

Pewnie ma, ale mówisz nie na temat. Skoro mówiliśmy o klasach, obiektach i
interfejsach w pojęciu obiektowym, to mówiliśmy o tym, co jest w projekcie
programu. Przytaczanie procesu jako obiektu uważam za zejście na boczny tor.

> > To jest chyba bajka z innego świata. Nie widziałem jeszcze klienta,
> > który by dyktował połowę kodu.

> A ja nie widziałem jeszcze klienta, który by pozostawił zdefiniowanie
> funkcjonalności programu programistom :)

Funkcjonalności tak. Ale nie implementowanie tej funkcjonalności w
poszczegónych klasach i podział tej funkcjonalności na poszczególne klasy. A
raczej to ma więcej wspólnego z interfejsami.

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

Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

[...]

>> A ja nie widziałem jeszcze klienta, który by pozostawił
>> zdefiniowanie funkcjonalności programu programistom :)
>
> Funkcjonalności tak. Ale nie implementowanie tej funkcjonalności 
> w poszczegónych klasach i podział tej funkcjonalności 
> na poszczególne klasy. A raczej to ma więcej wspólnego 
> z interfejsami.

Ja tu wywracam cały computing science do góry nogami, a Ty mi 
o jakichś interfejsach ;)