System programowania X-Windows i aplikacji Motif jest oryginalnie napisany w C. Mimo to jest on obiektowy, czego dowody można znaleźć w książce Douglasa A. Younga "The X Window System Programming and Applications with Xt OSF/Motif Edition". Wiadomo, że przy pomocy Motifa zdefiniowany został Winow Menager. Należałoby opowiedzieć o jakimś obiektowym systemie programowania okienek i aplikacji (np. Motifie). Pożądane byłoby zbadać, czy KDE i Gnome to tylko Window Menagery, czy mogą dla programisty okienek, czy aplikacji pełnić podobną rolę jak Motif.

I/lub/zamiast można by opowiedzieć o Window Builderze w Smalltalk Expressie lub Window Composerze w Smalltalk Dolphinie.

We wszystkich omawianych przypadkach należy zwrócić uwagę, że rejestracja call backu odbywa się dynamicznie zamiast po prostu deklaracji odpowiedniej metody wirtualnej.

Można omówić Swinga/AWT. Należy zwrócić przy tym uwagę na fakt, że mimo, że call backi są metodami wirtualnymi, to i tak trzeba je rejestrować dynamicznie (netodą addActionListener). Fakt, że call backi są metodami wirtualnymi może wynikać wyącznie z faktu, że w Javie nie ma pointerów do funkcji.

Multidispatching

Multidispatching to mechanizm wirtualizacji metody nie tylko ze względu na odbiorcę, ale i ze względu na niektóre z parametrów. Jeśli umówimy się, że odbiorca jest przedstawiany jako pierwszy parametr metody (standardowa metoda implementacji) to multidispatching będzie wirtualizacją ze względu na więcej niż jeden parametr.

A oto przykład doubledispatchingu realizującego dodawanie dwóch liczb, zapisanego w notacji Pascalopodobnej.

virtual function add( n1, n2: Number): Number;

function add( i1, i2: Integer): Integer;
begin
    (* instrukcja maszynowa dodowania stałoprzecinkowego *)
end;

function add( r1, r2: Real): Real;
begin
    (* instrukcja maszynowa dodowania zmiennoprzecinkowego *)
end;

function add( i: Integer; r: Real): Real;
begin
    add := add( convertToReal(i), r);
end

function add( r: Real; i: Integer): Real;
begin
    add := add(r, convertToReal(i));
end

Wszystko to akurat dałoby się zrobić przy pomocy przeciążania (overloadingu), ale są przypadki gdy tak się nie da. W szczególności dynamiczną kontrolę typów, występującą w Javie przy realizacji operatora isInstaceOf można zrealizować w oparciu o multidispatching (zakładając, że klasy są obiektami). A w Smalltalku overloading można realizować włącznie w oparciu o multidispatching. który na dodatek trzeba samemu zręcznie zasymulować.

Warto zauważyć, że w wypadku multidispatchingu, inaczej niż dla metod wirtualnych, może wystąpić błąd przy wywołaniu. Np. gdybyśmy w powyższym dodawaniu pominęli jedną z funkcji dokonujących konwersji to jej wywołanie powodowałoby bład dynamiczny. Jest to sytuacja podobna do overloadingu, z tym, że tam ewentualne błędy występują statycznie.

Przypuszczam, że A.Zaroda zna nazwę przynajmniej jednego języka z multidiapatchingiem. Warto zaczerpnąć z tego języka pełną definicję tego mechanizmu.

Metody ochrony danych w językach obiektowych.

W Javie i C++ występują modyfikatory private i protected służące do ochrony danych przed niepowołanym dostępem. W obu językach ochronę tę można przełamać. Gdyby tak nie było, ułatwiłoby to dowodzenie własności programów.

Mechanizm private w Javie możnaby scharakteryzowć jako udostępnianie atrybutu swojej klasie obiektow. Warto jeszcze rozważyć inny mechanizm, polegający na udostępnianiu atrubutu przez obiekt wyłacznie samemu sobie. Taki mechanizm często mamy na myśli specyfikując w Smalltaku (przy pomocy komentarza) metodę jako private.

Można porównać klauzule hidden i close z Loglanu z protected i private oraz rozważyć przydatność klauzuli taken.

Rozważane do tej pory metody są w pełni statyczne tj. zarówno definiowalne jak i weryfikowalne w czasie kompilacji. Warto rozważyć i porównać rownież metody dynamiczne, których przykładem jest autoryzowany dostęp użytkownika do bazy danych.