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), czy rodziców/dzieci okien, 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)

Głownie zastanawiam się, w którym "wymiarze" taki pomysł na "Kontekst"
byłby najlepszy. Czy z jakimś wzorcem projektowym powinienem się
zaprzyjaźnić?

*) nie chodzi (chyba ???) o kontekst w sensie biblioteki wątkowej, ani
nie w znaczeniu dla systemów serwerowych.

do góry

Wg mnie sprawa jest prosta to coś co nazywasz kontekst to po staremu
nazywa się "opcja". I tu są 2 opcje dla użytkownika - opcja krótkiej
daty i długiej (tak jest w Windows - a oni już chyba to przemyśleli).
Problem jedynie polega na tym, że u Ciebie nie kiedy trzeba dodać tą
skróconą nazwę dnia tygodnia. Więc w opcjach programu można dodać jakąś
literkę do formatu daty (najlepiej respektując format z ustawień
Windows), można też dodać trzeci format daty np. "data średnio długa"
która by mogła być zdefiniowana z tym nieszczęsnym skrótem dnia tygodnia.

W sumie to można by zrobić w opcjach tabelę "Daty" i tam zapodać 2
domyślne (długą i krótką). I dla dziwaków zrobić możliwość definiowania
innych formatów (najlepiej z nazwami tekstowymi a nie numerycznymi)
które były do wyboru pod prawym klikiem tam gdzie pojawiają się daty. Bo
znając użytkowników za jakiś czas będą mieli kolejny patent na
ulepszenie wyświetlania dat "w niektórych miejscach"...

do góry

W dniu 2011-09-27 16:50, Szyk pisze:
> Wg mnie sprawa jest prosta to coś co nazywasz kontekst to po staremu
> nazywa się "opcja".

Widzę, że pisząc o obrazach "przed oczyma duszy mojej" wyraziłem się
nieprecyzyjnie. Jest gdzieś 'globalny' format daty, jest przełączany
doraźnie na taki, jak potrzebny (aka przełączenie kontekstu), myslę
najbardziej o automatycznym powrocie.

Mniej o sam format daty, niech będzie, że ekran przeznaczony do obsługi
dwoma palcami lewej ręki podczas rozmowy telefonicznej (głupi przykład),
coś tam przełącza (kolory, obojętne) po czym ma być
a) gwarantowany powrót.
b) zmiana parametru nie musi nastąpić, więc szukamy odpowiednika
(defaltu) głębiej.

Za czasów sekwencyjnych programów pod DOS-a robiło się to po prostu na
stosie, destruktory to ładnie przywracały. Wtedy 'przestrzeń powracania'
była jednowymiarowa, jak stos. Na dziś nawet nie wiem, ile wymiarów
można wymyślić. Np Ty podałeś wymiar personalny, Jasiek ma tak, Zośka ma
siak.

do góry

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.

do góry

> medytuję nad słowem "Kontekst"...

> I wymyśliłem sobie, że funkcje różnych poziomów szukają właśnie
> "Kontekstu".

Moim zdaniem to jest polimorfizm dynamiczny. Dopasowanie metody
na podstawie typu parametru w czasie wykonania programu.

Pozdrawiam



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

Dobra chyba wiem już o co pytasz.

Ja jestem zdania by rozwiązania były tak proste jak to tylko możliwe
(jednak zapewniające osiągnięcie celu). W tym przypadku poleciłbym
zastosowanie wzorca singleton który by zawierał wszystkie opcje programu
w czasie wykonania. Te opcje to hasz wartości. Ten singleton by miał
taki niestandardowy ficzer jak wewnętrzną listę zbiorów opcji (tych
haszów). Na samym początku listy był by hasz opcji wciąganych z pliku
konfiguracji. Natomiast specjalne klasy okien (rozpoczynające nowy
kontekst) wywoływały by na tym singletonie opcji metodę options.clone()
i np. options.setShortDataFormat("format ze skrótem dnia tygodnia").
Operacja clone powodowała by dodanie do wewnętrznej listy obiektu
options nowego pustego hasza. Natomiast options.setShortDataFormat
ustawiałby jedną zmienną w tym nowym haszu. Dostęp do pozostałych opcji
by następował przez przejście od końca listy do jej początku i zwrot
pierwszej napotkanej wartości.

To w sytuacji gdy jest jedna hierarchia okien i tylko jeden aktywny
kontekst. Jest to zdrowe dla użytkownika więc chyba ten pomysł powinien
wystarczyć (inaczej trzeba by stosować drzewo opcji zamiast tej
proponowanej listy).

Zaletą tego rozwiązania z singletonem jest fakt, że program staje się
modularny - opcje stoją z boku. Natomiast włączanie silnika opcji w
klasy poszczególnych okien (rejestr opcji w każdym oknie i
przeszukiwanie w górę hierarchii okien) jest moim zdaniem mataczeniem.
Choć było by to potencjalne rozwiązanie dla przypadku gdy jest wiele
hierarchii okien w programie.

do góry

On 27/09/2011 14:03, Jacek Czerwinski wrote:
> 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

chodzi Ci o coś takiego?
http://www.allankelly.net/patterns/encapsulatedconte
xt.html


B.

do góry

W dniu 2011-09-27 22:51, Bronek Kozicki pisze:
> On 27/09/2011 14:03, Jacek Czerwinski wrote:
>> medytuję nad słowem "Kontekst"...
>> Przy czym Kontekst *) mojej wypowiedzi jest na przykład taki:
>>
...
>>
>> 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
>
> chodzi Ci o coś takiego?
> http://www.allankelly.net/patterns/encapsulatedconte
xt.html
>

W jakiejś części tak, "avoid using long parameter lists" powinienem to
zasygnalizowac na początku.
Dodatkowo nosze jakąs ideę stosu, listy, drzewa (chmury?) tych kontekstów .
O ile (podkreślam, "o ile") drzewo, to takie zstępowanie danych jak w
LDAP, Active Directory itp: ty nie mam parametru/nie zajmujemy się tym
-> spuszczamy pytanie głębiej.

do góry

W dniu 2011-09-27 18:02, Piotr Chamera pisze:

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

Nieco inny stosunek do zmiennych miał chyba ś.p. Algol ???

> 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).

Dokładnie ta idea.

do góry

Jacek Czerwinski <...@...z.pl> napisał(a):

> medytuję nad słowem "Kontekst"...

no kontekst to ciekawa rzecz,

o ile wiem w c mozna pisac w sposob kontekstowy tylko
w ograniczonym czesciowym zakresie,

np powiedzmy ze w kazdym module chcialbym miec odrebnego
printf()'a ktory w pierwszym pisalby na konsole w drugim
na huda a w trzecim na jakis wyswietlacz na sprzecie (czy
cos takiego)

(o ile wiem to jesli te printfy byly by prywatne w modulach
to ok, ale jesli publiczne to bylby blad linkera)

mozliwe ze szkoda ze modulowka w c nie ma wsparcia do
'ewentualnych' przedrostkow dla modulow, np jesli ja w
module zdefiniuje sobie printf'a (o dokladnie takim
samym nagowku jak standardowy) i zainkluduje modul stdio
to wywolanie printfa w moim module lokalnie wywola mojego
printfa zas do tego z stdio bede mogl sie dostac przez

stdio.printf("lalala");


przedrostki bylyby opcjonalne (gdyby nie bylo lokalnego
to do tego z stdio tez mozna by sie dostac bez przedrostka)
(i zastanawiam sie czy to powinna byc kropka)

daloby to wieksza mozliwosc programowania 'kontekstowego'






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

do góry