W dniu 2011-09-27 15:03, Jacek Czerwinski pisze:
> medytuję nad słowem "Kontekst"...
> Przy czym Kontekst *) mojej wypowiedzi jest na przykład taki:
>
> Aplikacja, duża, biurowa. W większości części format daty jest dość
> typowy 27.09.2011, ale w części pokrewnej z wyznaczaniem terminów,
> planowaniem zdarzeń, użytkownicy polubili "27.09.2011 Wto".
> I teraz ja jako programista, bym chciał ten format przełączać, ale tak,
> żeby na festasty poziom wywołania nie przekazywać jeszcze jednego
> parametru.
>
> I wymyśliłem sobie, że funkcje różnych poziomów szukają właśnie
> "Kontekstu". Nie mam przemyśleń, czy zmiana kontekstu, i powrót do
> poprzedniego, byłby w wymiarze wywołań na stosie (dla aplikacji typu
> starego DOS-a idealnie),

Teraz to wyszło z ,,mody" ale kilka języków miało zmienne o zasięgu
,,dynamicznym" (dynamic scope) jak Common Lisp np.:

(defvar x 1)

(defun pisz () (princ x)

(pisz)

(let ((x 2))
(pisz))

(pisz)

wypisze po kolei
1
2
1

> czy rodziców/dzieci okien,

coś takiego zrobiono np. we frameworku webowym Zope w wersji 2, nazwano
to ,,acquisition". Jeśli obiekt nie potrafi znaleźć atrybutu u siebie,
szuka u rodzica, ten u swojego rodzica itd. aż do korzenia hierarchii.
Ponieważ jest to mechanizm domyślny, więc czasem trudno dojść skąd
pochodzi znaleziona wartość :) ,,Osie" po których odbywa się
przeszukiwanie można przedefiniować (tzn. w aplikacji mogą istnieć
różne, równoległe hierarchie obiektów).

> czy na podstawie
> hierarchii klas, zależności jaka jest między fabryką obiektów a jej
> tworzonymi obiektami, definicji użytkowych modułów i nie wiem jaki
> jeszcze da się wymyśleć. Nawet sesja w sensie webowym jest troszkę
> podobna do tej idei (zestaw informacji wleczony za zalogowanym userem),
> choć nie jest to tożsame.
>
> Zaznaczam, że z implementacją pewnie bym sobie poradził, np. na gruncie
> Javy używam kilku uznanych bibliotek konfiguracyjnych, na C++ coś
> swojego. Wyobraźmy sobie jako swoisty Map<String,String>, klient pyta, a
> "coś" (co jest odnalezione automatycznie, ten właśnie silnik kontekstu)
> mu odpowiada (ew. jak nie wie, przekazuje oczywiście pytanie dalej)

Coś podobnego zrobiono w Zope 3 (zope component architecture).
W uproszczeniu: na różnych poziomach hierarchii obiektów w aplikacji
(obiektów, nie klas) pojawiają się rejestry, w których można
zarejestrować komponenty. Obiekty mogą pytać o komponenty realizujące
zadany interface. Jeśli rejestr nie ma zarejestrowanego komponentu
realizującego żądany interface, może przekazać zapytanie do rejestru
wyżej w hierarchii. Zwracany jest obiekt realizujący szukany interface.