Welcome Guest Search | Active Topics | Members | Log In

Wirtualne pointery - co mamy i co zyskać powinniśmy? Options · View
habela
Posted: Friday, March 25, 2005 1:28:02 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Nadrabiałem wczoraj potężne zaległości w lekturze forum, czytając wątek o wirtualnych pointerach. Cieszę się że wygrało klarowne podejście do sprawy ziaren. Zostałem też w końcu przekonany, że point_to (albo points_to?) nie burzy estetyki mechanizmu.
(Dodam przy okazji, że przyrównanie on_retrieve do points_to jest dobrym argumentem, że pomysł nie burzy tradycyjnej koncepcji. Ale moim zdaniem nie wolno tych dwóch operacji utożsamiać, bo chyba byśmy się skutecznie zapętlili.)
Myślę, że problem został uchwycony dość zgrabnie. Jednak nie zrezygnuję to z pytania / sprawdzenia, co nam (za cenę wprowadzenia jakby nie było dodatkowych konstrukcji programistycznych) - zostało w dłoni!

Zatem pozwolę sobe spojrzeć z nieco dalszej perspektywy i rozpocząć od dość fundamentalnych pytań.

A) Po co nam (na razie - konkretne) pointery?
0. Niezbędne w językach/modelach gdzie zagnieżdżanie złożonych podobiektów jest niedozwolone.
1. Uniknięcie nadmiarowości, gdy określone dane są dostępne w wielu miejscach (znaczy - działanie w stronę normalizacji). Ma to u nas dwa aspekty:
1a. Brak dublowania tych samych danych (wartość/zawartość) - niepotrzebna konsumpcja zasobów i groźba niespójności.
1b. Brak nieuzasadnionego dublowania tożsamości. Tzn. jeśli zgodnie z logiką biznesową w wielu miejscach występuje ta sama dana, to powinna oferować nie tylko tę samą wartość, ale też posiadać ten sam identyfikator/tożsamość.
2. Możliwość sięgnięcia (za pomocą odnośnika) strukturą danych poza lokalnie stworzoną definicję - ogranicza poziom niezbędnego zagnieżdżenia i pozwala tworzyć nie hierarchiczne struktury. Innymi słowy - jeden poziom zagnieżdżenia w definicji każdego obiektu jest wystarczający dla uzyskania dowolnej liczby kroków nawigacji w skonstruowanej przezeń strukturze.
3. [Skoro zdecydowaliśmy się na powyższe] - Możliwość podtrzymania integralności referencyjnej i nawigacji w obu kierunkach.

B) W systemie ODRA - pozostają w mocy motywy 1,2,3.
Zakładamy, że mechanizmy konkretnych związków asocjacyjnych wypełniają (a w każdym razie - mogą bez trudu zrealizować) wszystkie sformułowane tu wymagania.

C) Co mają zapewnić wirtualne pointery w ODRA?
Powinny wypełnić zadania 1,2,3 oraz jedno dodatkowe:
4. Skutecznie (przezroczyście) udawać pointery konkretne, które ktoś mógł potrzebować dla realizacji cech 1,2,3.
Załóżmy, że nic nowego na razie nie wprowadziliśmy. Jak sobie radzi z problemem "zwykły" tradycyjny mechanizm perspektyw?
Ad. 1a. Perspektywa wirtualna z natury rzeczy stanowi odnośnik do innych danych, więc problem dublowania danych nie występuje.
Ad. 2. Jak wyżej - można odnieść się do danych konkretnych oraz do danych z innej perspektywy.
Ad. 3. Dzięki możliwości odwołania do obiektu zawierającego - istnieją tu niezbędne środki.
Ad. 4. Wydaje mi się, że poprzez zagnieżdżanie perspektyw i odpowiednie definicje virtual objects - można uzyskać dla użytkownika wrażenie normalnej nawigacji po wskaźnikach.
Ad. 1b. Tu jest problem. Jeśli w perspektywie obiektu złożonego Emp umieścimy perspektywę works_in a w niej perspektywę Dept, to choć Kowalski i Nowak pracują w "Sales" to ów wirtualny Dept (byłby reprezentowany przez dwa różne - w sensie tożsamości (identyfikatory wirtualne!) - obiekty).

Nie chcę tu na razie formułować alternatywnych pomysłów - bo być może coś przeoczyłem i moja krytyka jest chybiona.
Natomiast jeśli powyższe uwagi okazałyby się trafne, to:
a) Bez rozwiązania problemu 1b inwestycja w konstrukcję virtual pointers / points_to może okazać się niewarta podejmowania. (Efekt możliwy do uzyskania przez zagnieżdżanie, a przecież w obu wypadkach programista musi bardzo wnikliwie dbać o spójność takich definicji - czy dodatkowa specjalizacja konstrukcji istotnie go w tym wspomoże?). Tę intuicję wyraził w pewnym miejscu Krzysiek, gdy na początku dyskusji sugerował, aby po prostu zagnieździć definicję perspektywy opisującej obiekt docelowy.
b) Obiekt docelowy (który ma być określany przez points_to) powinnny charakteryzować:
- możliwość skonstruowania "od zera" oraz możlwość posiadania dowolnie zagnieżdżonych podobiektów (w tym innych wskaźników);
- uczynienie identyfikatora (virtualnego) obiektu docelowego niezależnym od identyfikatora obiektu zawierającego wirtualny pointer;
- możliwość, aby docelowy obiekt wirtualny wskaźnika był określony osobno (zewnętrznie w stosunku do bieżącej) zdefiniowaną perspektywą (by ścieżki nawigacji po wirtualnych pointerach mogły być dłuższe niż poziom zagnieżdżenia perspektyw);
- możliwość przekazania do tej perspektywy obiektu docelowego informacji o obiekcie zawierającym wirtualny wskaźnik (np. celem stworzenia asocjacji zwrotnej).
radamus
Posted: Saturday, March 26, 2005 2:06:18 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
habela wrote:
(Dodam przy okazji, że przyrównanie on_retrieve do points_to jest dobrym argumentem, że pomysł nie burzy tradycyjnej koncepcji. Ale moim zdaniem nie wolno tych dwóch operacji utożsamiać, bo chyba byśmy się skutecznie zapętlili.)
Myślę, że problem został uchwycony dość zgrabnie. Jednak nie zrezygnuję to z pytania / sprawdzenia, co nam (za cenę wprowadzenia jakby nie było dodatkowych konstrukcji programistycznych) - zostało w dłoni!


Na seminarium ustaliliśmy, że point_to zastąpimy zgrabniejszym on_navigate (jako kontynuacja nazewnictwa procedur w perspektywach).
Czy point_to (od teraz będę używał on_navigate) nie powinniśmy utożsamiać? Cały czas szukam przykładu kiedy należałoby rozróżnić, z pragmatycznego punktu widzenia, operację dereferencji na pointerze:
Code:
deref(Emp.works_in);


oraz operacji przejścia po pointerze
Code:
Emp.works_in.Dept;


Jeżeli programista definiujący perspektywę, potrzebuje wykonać inne akcje w razie gdy ktoś wywołuje dereferencje niż gdy nawiguje to faktycznie jest taka potrzeba. Załóżmy, że musi pisać coś na log.

Code:
...
create view works_inDef {
virtual_objects works_in { return ziarno_Emp.works_in as wis;}
on_navigate { writeLog("User" + CurrentUser+ "nawigacja"); return deref(wis); }
on_retrieve { writeLog("User" + CurrentUser+ "dereferencja"); return deref(wis); }
on_update (newDeptRef) {writeLog("User" + CurrentUser+ "aktualizacja"); wis = newDeptRef; }

}
...

Tylko czy to ma sens? Może ktoś znajdzie lepszy przykład bo normalnie dla rzeczywistych mamy zależność:
Code:
Emp.works_In.Dept.name == deref(Emp.works_in).name

Z resztą stąd nasze utożsamienie. Jeżeli, na przykład, chcemy zrobić wirtualny pointer "write only" to i tak musielibyśmy zabronić i on_retrieve i on_navigate.

Przy okazji załączam moją prezentację z seminarium (w oryginalnej formie).

http://www.kis.p.lodz.pl/~radamus/odraforum/wirtualne_pointery.ppt

Kilka uwag do Twoich fundamentalnych pytań.

Staraliśmy się z Krzyśkiem myśleć poprzez analogię do obiektów rzeczywistych.
Zakładając istnienie pointerów rzeczywistych, oraz zakładając, że programista rozumie ich intencje jako elementów implementujących asocjacje występujące w dziedzinie biznesowej nie zgodziłbym się z tym, że można wewnątrz obiektu pointerowego zdefiniować "wskazywany" obiekt. Oznaczało by to tan na prawdę, żę pointer jest po prostu obiektem złożonym. Programista definiując wirtualny pointer ustala tylko na co on pokazuje. Natomiast sama definicja jest zewnętrzna, tai jest model biznesowy (przecież podobiektem pracownika nie jest obiekt Firmy). Nie chcemy tu uzyskać tylko, jak to napisałeś "wrażenia nawigacji" ale również naturalne odzworowanie asocjacji.




habela wrote:


Ad. 1a. Perspektywa wirtualna z natury rzeczy stanowi odnośnik do innych danych, więc problem dublowania danych nie występuje.


Tak ale na zupełnie, moim zdaniem, innym poziomie. Odnośnik w sensie, że jest definiowana na podstawie jakichś danych ale:
- nie zawiera tych danych w sensie agregacji
- nie prowadzi do tych danych w sensie asocjacji
Definicja jest po prostu zalezna od tych danych. Na przykład Perspektywa bogaty pracownik jest zależna od obiektów (wirtualnych lub rzeczywistych) pracownika.

habela wrote:


Ad. 1b. Tu jest problem. Jeśli w perspektywie obiektu złożonego Emp umieścimy perspektywę works_in a w niej perspektywę Dept, to choć Kowalski i Nowak pracują w "Sales" to ów wirtualny Dept (byłby reprezentowany przez dwa różne - w sensie tożsamości (identyfikatory wirtualne!) - obiekty).

Też tak uważam, poza tym Dept powinien być zdefiniowaly zewnętrznie do Emp. Zakładając, że w Dept istnieą pointery employs prowadzące do Emp, musielibyśmy definiować perspektywę Emp wewnatrz pointera employs? A w środku works_in z Dept? Nie bardzo mogę to sobie wyobrazić.
Z on_navigate nie definiujemy Dept wewnątrz works_in tylko definiujemy "przejście po pointerze", czyli zapytanie, które zwróci referencje do obiektu Dept, zdefiniowanego zewnętrznie.

habela wrote:

b) Obiekt docelowy (który ma być określany przez points_to) powinnny charakteryzować:
- możliwość skonstruowania "od zera" oraz możlwość posiadania dowolnie zagnieżdżonych podobiektów (w tym innych wskaźników);

Przy założeniu, że wirtualny pointer ma on_navigate tak jest bo definicja jest zewnętrzna. Generalnie, poprzez analogię do rzeczywistych pointerów, które są tak na prawdę obiektami prostymi, nie można wewnątrz wirtualnego pointera zdefinować podperpektyw.

habela wrote:

- uczynienie identyfikatora (virtualnego) obiektu docelowego niezależnym od identyfikatora obiektu zawierającego wirtualny pointer;
- możliwość, aby docelowy obiekt wirtualny wskaźnika był określony osobno (zewnętrznie w stosunku do bieżącej) zdefiniowaną perspektywą (by ścieżki nawigacji po wirtualnych pointerach mogły być dłuższe niż poziom zagnieżdżenia perspektyw);


virtual_objects obiektu pointerowego definiuje ziarna wirtualnego pointera. on_navigate zwraca identyfikator (wirtualny bądź nie) obiektu wskazywanego (ale zdefiniowanego zewnętrznie). Docelowy obiekt musi być zdefiniowany osobno. Jak go nie ma to nie można definiować do niego (nawet wirtualnego) pointera. Programista definiujący pointer, nie ważne, czy wirtualny czy rzeczywisty wykorzystuje zewnętrzną definicję. Różnica pomiędzy definicją rzeczywistego a wirtualnego pointera jest taka, że w tym drugim przypadku programista musi zdefiniować proces nawigacji. Ale nie zdefiniować sam obiekt wskazywany, tylko zdefiniować co oznacza przejście po pointerze. To pointer ma być wirtualny. Przecież podczas definiowania rzeczywistego pointera programista nie tworzy definicji obiektu wskazywanego. Wykorzystuje istniejącą.

habela wrote:

- możliwość przekazania do tej perspektywy obiektu docelowego informacji o obiekcie zawierającym wirtualny wskaźnik (np. celem stworzenia asocjacji zwrotnej).

Zakładam, że nie ma czegoś takiego jak "perspektywa obiektu docelowego".


Czyli podsumowując:
1. Wirtualne pointery, przy założeniu istnienia rzeczywistych pointerów są naturalnym rozszerzeniem perspektyw zwiększającym ich przezroczystość.
2. Podejście stosowe zakłada istnienie obiektów pointerowych umożliwiających modelowanie asocjacji. samo zagnieżdżanie w tej sytuacji nie wystarczy. Bez tego pozostawały by nam tylko związki klucz główny - klucz obcy.
3. Zakładając potrzebę istnienia rzeczywistych pointerów wracamy do punktu 1.

Przepraszam, że tak wyrywkowo, ale święconka czeka.
Przy okazji życzę wszystkim forumowiczom spokojnych wiosennych Świąt.
habela
Posted: Saturday, March 26, 2005 3:59:05 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Zacznę od tego, że uspokoiłeś mnie co do jakości mechanizmu wskaźników. Byłe zatroskany o to, aby dwa wirtualne wskaźniki w dwóch różnych wirtualnych obiektach mogły wskazywać na obiekt (również wirtualny) o tym samym oid.
radamus wrote:
Zakładam, że nie ma czegoś takiego jak "perspektywa obiektu docelowego".

Chodzi mi o to, że musi takowa istnieć, jeśli obiekt docelowy jest obiektem wirtualnym. Zgadzamy się, że powinna ona wówczas być zdefiniowana zewnętrznie.

Aby nie rozwlekać posta - wydaje mi się, że tp jak działa on_navigate wszystkim nam się podoba. Ale trzeba rozstrzygnąć to poniżej.
radamus wrote:
Na seminarium ustaliliśmy, że point_to zastąpimy zgrabniejszym on_navigate (jako kontynuacja nazewnictwa procedur w perspektywach).
Czy point_to (od teraz będę używał on_navigate) nie powinniśmy utożsamiać? Cały czas szukam przykładu kiedy należałoby rozróżnić, z pragmatycznego punktu widzenia, operację dereferencji na pointerze

Przy objaśnionym przez Ciebie sposobie działania on_navigate - to utożsamienie zaczyna brzmieć całkiem przekonująco.
De-referencja kojarzy mi się z uzyskaniem wartości, która kryje się za danym obiektem. Jeśli dokonujemy jej na obiekcie pointerowym, to istotnie logiczne jest, żeby był to identyfikator docelowego. Zatem specyfiką obiektu pointerowego jest to, że jest to prawdopodobnie jedyny rodzaj obiektu, po dereferencji którego dostajemy l-value. Czy tak jest i czy to jest ok?
(Natomiast, jeśli dereferencja miałaby tak rekursywnie i "do skutku" zamieniać obiekty na struktury wartości, to wtedy za rozróżnieniem przemawia groźba zapętlenia.)
Nie jestem na bieżąco, więc wobec powyższego muszę zupełnie serio zapytać: czy ten ostatni slajd z prezentacji to był żart, czy też rzeczywiście konkluzja jest taka, że virt. pointer to podobiekt równie dobry jak każdy inny i że problemu nie ma?
Odniosłem wrażenie, że jeśli istotnie wolno nam utożsamić on_retrieve z on_navigate, to jakiekolwiek specjalne konstrukcje językowe dla wirtualnych pointerów są zbędne. (Co jest dla mnie o tyle niewesołe, że niweczy nam sposobność napisania artykułu na ten temat ;)
radamus
Posted: Saturday, March 26, 2005 8:47:44 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
habela wrote:

Przy objaśnionym przez Ciebie sposobie działania on_navigate - to utożsamienie zaczyna brzmieć całkiem przekonująco.
De-referencja kojarzy mi się z uzyskaniem wartości, która kryje się za danym obiektem. Jeśli dokonujemy jej na obiekcie pointerowym, to istotnie logiczne jest, żeby był to identyfikator docelowego. Zatem specyfiką obiektu pointerowego jest to, że jest to prawdopodobnie jedyny rodzaj obiektu, po dereferencji którego dostajemy l-value. Czy tak jest i czy to jest ok?

Tak własnie jest. Taka jest idea pointerów - dereferencja zwraca referencję.

habela wrote:


Odniosłem wrażenie, że jeśli istotnie wolno nam utożsamić on_retrieve z on_navigate, to jakiekolwiek specjalne konstrukcje językowe dla wirtualnych pointerów są zbędne. (Co jest dla mnie o tyle niewesołe, że niweczy nam sposobność napisania artykułu na ten temat ;)

Nie do końca. Utożsamiamy w kwestii zwracanej wartości. Różnica jest na poziomie ENVS. on_navigate jest wykonywane również wtedy gdy operator nie-algebraiczny przetwarza obiekt pointerowy. Normalnie dla zwykłego obiektu wirtualnego on_retrieve jest wywoływane tylko w przypadku dereferencji. Dlatego wprowadziliśmy on_navigate. Mechanizm musi wiedzieć, że na do czynienia z wirtualnym pointerem. Po prostu, jeżeli w definicji perspektywy jest on_navigate to, oprócz nested(seed), jego wynik (a właściwie binder z nazwą obiektu, którego referencję zwróci on_navigate) jest wrzucany na stos. Dzięki takiemu rozwiązaniu nie ma zmian w wirtualnych identyfikatorach (nie musimy rozróżniać identyfikatora wirtualnego pointera od identyfikatora wirtualnego obiektu). Zakładając, że utożsamiamy on_navigate z on_retrieve na poziomie zwracanej wartości to dla obiektu pointerowego on_navigate gra również rolę on_retrieve.

Także myślę, że niepotrzebnie się niepokoisz. Jest o czym pisać artykuł. Do czego niniejszym zachęcam.
stencel
Posted: Sunday, March 27, 2005 12:28:57 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
No własnie kmotrzy, coś żeśta pokrecili, ale widac ze jest juz wyprostowane przez Radka.

Urwalem sie jakis czas po Exultet (podziwiam gosci, ktorzy to jednym tchem spiewaja) i wlasnie chce potwierdzic, co pisze Radek.

Oto mozemy miec on_retrieve zamiast on_navigate, ale wtedy musimy miec inny sposob syntaktycznego oznaczenia, ze w wypadku wirtuanego pointera na ENVS odklada sie wynik on_retrieve/on_navigate. Widac wiec dwie ocje:

1. [on_navigate] == wirtualny pointer rozni sie od wirtualnego obiektu atomowego tym ze ma on_navigate.

2. [as pointers vel. Subi04] == wirtualny pointer ma fraze "as pointers" w definicji virtual objects.

Ja osobiscie preferuje 1.
subieta
Posted: Sunday, March 27, 2005 8:05:56 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
radamus wrote:
Jest o czym pisać artykuł. Do czego niniejszym zachęcam.

Ja tez. Sadze jednak, ze artykul traktujacy bezposrednio o wirtualnych pointerach bylby na dzien dzisiejszy niezrozumialy dla wybitnych przedstawicieli spolecznosci baz danych, z ktorych rekrutuja sie potencjalni recenzenci takiego artykulu. Taki artykul nalezaloby ustawic w wyraznie pragmatycznym kontekscie, najlepiej w kontekscie views do XML lub (nieco gorszy wariant) w kontekscie relacyjnych baz danych i zwiazkow klucz glowny/klucz obcy modelowanych jako wirtualne pointery.
radamus
Posted: Sunday, March 27, 2005 8:07:50 AM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
stencel wrote:

1. [on_navigate] == wirtualny pointer rozni sie od wirtualnego obiektu atomowego tym ze ma on_navigate.

2. [as pointers vel. Subi04] == wirtualny pointer ma fraze "as pointers" w definicji virtual objects.



W 2. przypadku informacja o tym, że mamy do czynienia z virtualnym pointerem musi być przechowywana w wirtualnym identfikatorze. Czyli musimy wprowadzić nową flagę "I'm virtual pointer" (jak proponowała Hania).
W 1. przypadku wirtualny identyfikator pozostaje bez zmian. Jeżeli jest on_navigate to mamy do czynienia z pointerem, jeżeli jest nie to mamy wirtualny obiekt atomowy. Mnie również bardziej odpowiada to rozwiązanie. Jest tylko jedna rzecz, która nie daje mi spokoju. Rozważmy dwie poniższe definicje podperspektyw wirtualnego pracownika:

Wirtualny pointer tylko do zapisu - brak on_navigate
Code:
...
create view works_inDef {
virtual_objects works_in { return ziarno_Emp.works_in as wis;}
on_update (newDeptRef) { wis = newDeptRef; }
}

...


wirtualny obiekt atomowy tylko do zapisu - brak on_retrieve
Code:
...
create view salaryDef {
virtual_objects salary { return ziarno_Emp.salary as ss;}
on_update (newSal) { ss = newSal; }

}

...


Definicje są nierozróżnialne z punktu widzenia typu wirtualnego obiektu. Czy wirtualny pointer czy wirtualny obiekt atomowy jest tak samo.
Ale przecież aktualizacja rzeczywistych obiektów pointerowych i atomowych odbywa się inaczej.

Code:
(Emp where name == "Noe").works_in = ref(Dept where name == "promotion");

ref bo musimy zapobiec dereferencji.

Code:
(Emp where name == "Noe").salary = 2000;


Skąd użytkownik wirtualnego obiektu ma wiedzieć, że w pierwszym przypadku jest to obiekt pointerowy i musi podstawić referencję? Odpowiedź brzmi: zna schemat. Czyli definicja schematu musi jednak jakoś pokazać, że mamy do czynienia z wirtualnym pointerem. W powyższym przykładzie nie pokazała. Czyli "as pointer" czy "virtual pointers" nie do końca można odrzucić.

Wyprowadźcie mnie z błędu jeżeli się mylę.
habela
Posted: Sunday, March 27, 2005 10:01:13 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
radamus wrote:
Różnica jest na poziomie ENVS. on_navigate jest wykonywane również wtedy gdy operator nie-algebraiczny przetwarza obiekt pointerowy. Normalnie dla zwykłego obiektu wirtualnego on_retrieve jest wywoływane tylko w przypadku dereferencji. Dlatego wprowadziliśmy on_navigate. Mechanizm musi wiedzieć, że na do czynienia z wirtualnym pointerem.

OK - chyba czuję się przekonany. Czyli brak jest niezawodnych kryteriów, które w oparciu o analizę typu rezultatu operacji on_retrieve rozstrzygnęłyby, czy mamy do czynienia z prostym obiektem zagnieżdżonym, czy też ze wskaźnikiem. Zatem trzeba zróżnicować sposobem zapisu w definicji perspektywy.
A nawet, gdyby można było (bo chyba tak) na podstawie budowy on_retrieve określić, czy jest to obiekt prosty trzymający wartość, czy też pointer, to nie ma sensu komplikować. Tym bardziej, że konieczność explicite oznaczenia czegoś jako pointera będzie dodatkową linią obrony przed błędem programisty (który np. chiałby zrobić obiekt prosty a wyszedł mu w on_retrieve pointer lub odwrotnie).
Czyli zotaje tylko pytanie, gdzie umieścić to rozróżnienie.

stencel wrote:

1. [on_navigate] == wirtualny pointer rozni sie od wirtualnego obiektu atomowego tym ze ma on_navigate.

2. [as pointers vel. Subi04] == wirtualny pointer ma fraze "as pointers" w definicji virtual objects.

Ja osobiscie preferuje 1.

Mnie z tych dwóch bardziej odpowiada 2. Uważam, że wbrew pozorom (tu i tam plus jedno słowo kluczowe) - cechuje je mniejsza złożoność w języku.

radamus wrote:
Zakładając, że utożsamiamy on_navigate z on_retrieve na poziomie zwracanej wartości to dla obiektu pointerowego on_navigate gra również rolę on_retrieve.

No właśnie - skoro gra rolę on_retrieve, to pozwólmy mu tak samo się nazywać.

radamus wrote:
W 2. przypadku informacja o tym, że mamy do czynienia z virtualnym pointerem musi być przechowywana w wirtualnym identfikatorze. Czyli musimy wprowadzić nową flagę "I'm virtual pointer" (jak proponowała Hania).
W 1. przypadku wirtualny identyfikator pozostaje bez zmian. Jeżeli jest on_navigate to mamy do czynienia z pointerem, jeżeli jest nie to mamy wirtualny obiekt atomowy. Mnie również bardziej odpowiada to rozwiązanie.

Ten argument mało mnie przekonuje. Jeśli oba warianty mają znaczyć to samo, to dlaczego rozwiązanie syntaktyczne miałoby nam narzucić, w jaki sposób sobie wewnętrznie oznaczyć wirtualny pointer. Ja ten problem podnoszę tylko z punktu widzenia prostoty dla programisty oraz jednorodności składni DDL.

A w ogóle to preferuję rozwiązanie nr 3 - słowo kluczowe ref przed całą perspektywą definiującą pointer. Składnia identyczna z asocjacjami konkretnymi i jej ujednolicenie z interfejsami (patrz - dokumentacja w html nt. interfejsów) nie wymaga żadnych zmian.
Przypomnę, że proponowana ujednolicona z interfejsami składnia dla perspektyw przewidywała coś takiego (pod nazwą virtual feature):
Code:
    contact[0..*]:
        virtual { /* definicja ziaren */ } supports /* ewentualna hermetyzacja przez podanie nazwy interfejsu */ {
                    /* tutaj podobiekty (podperspektywy) i operacje generyczne */
        };
    }

Ponieważ zwyczajna, konkretna asocjacja jest tam opisywana następująco:
Code:
export Employee {
    worksIn : ref Department update    reverse employs;
}


To w wypadku proponowanego rozwiązania, wystarczyłoby mi przed virtual słowo kluczowe ref.

radamus wrote:
Skąd użytkownik wirtualnego obiektu ma wiedzieć, że w pierwszym przypadku jest to obiekt pointerowy i musi podstawić referencję? Odpowiedź brzmi: zna schemat. Czyli definicja schematu musi jednak jakoś pokazać, że mamy do czynienia z wirtualnym pointerem. W powyższym przykładzie nie pokazała. Czyli "as pointer" czy "virtual pointers" nie do końca można odrzucić.

No właśnie - tu jest chyba dodatkowa przewaga as_pointers lub (chyba zwłaszcza) rozwiązania nr 3 nad on_retrieve.
stencel
Posted: Sunday, March 27, 2005 10:35:34 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Code:
(Emp where name == "Noe").works_in = ref(Dept where name == "promotion");


radamus wrote:
ref bo musimy zapobiec dereferencji.


No wlasnie tego nie rozumiem. Znow mam zastrzezenia bazowe, ale wydaje mi sie, ze zapytanie Dept where name == "promotion" zwraca referencje! Co daje otoczenie tego wywolaniem funkcji ref?

Z wypowiedzi Radka rozumiem, ze jest to taki marker dla interpretera, zeby nie robil dereferencji. Czyli, ze wyniki zapytań Dept where name == "promotion" i ref(Dept where name == "promotion") są identyczne. Ale to drugie jest do tego jakoś sprytnie zamarkerowane na poziomie drzewa składni.

Jakoś wydaje mi się to paskudne, bo na poziomie wywolan funkcji jest to samo, ale na jakimś meta-poziomie nie to samo.

Rowność w cytowanym na początku kodzie dostaje po lewej stronie OID i1 obiektu <i1, works_in, i2> a po prawej stronie dostaje OID i3 jakiegos obiektu Dept. Co tu z czym jest porownywane?
Czy nie powinnismy jakos poklasyfikowac roznych smakow rownosci, a potem dopiero zastanawiac sie nad skladnia?

----------------------obiekt atomowy obiekt zlozony obiekt pointerowy
----------------------<i1,..., v1>-------<i2, ..., S2>---<i3,...,i4>
obiekt atomowy
<j1,...,w1>------------v1=v2--------------false--------false
obiekt zlozony
<j2,...,T2>--------------false--------T2=S2?i2=j2-----false
obiekt pointerowy
<j3,...,j4>---------------false--------------false--------j4=i4?i3=j3


radamus
Posted: Sunday, March 27, 2005 12:30:57 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
stencel wrote:
Code:
(Emp where name == "Noe").works_in = ref(Dept where name == "promotion");


radamus wrote:
ref bo musimy zapobiec dereferencji.


No wlasnie tego nie rozumiem. Znow mam zastrzezenia bazowe, ale wydaje mi sie, ze zapytanie Dept where name == "promotion" zwraca referencje! Co daje otoczenie tego wywolaniem funkcji ref?



Zaraz zaraz.
Najpierw ustalę
" = " to u mnie operator podstawienia
" == " to operator porównania

Klucz to działanie operatora podstawienia, jego semantyka jest następująca:

q1 = q2
q1 jako l-value musi zwrócić referencję
q2 (zakładając, że nie jest makroskopowy - patrz książka szefa str. 312) musi zwrócić jedną wartość. I jako r-value podlega dereferencji.

działanie

referencja = deref(q2)

Podstawienie na obiekt atomowy:
Niech pracownik Doe ma taką samą pensję jak pracownik Poe.

Code:
(Emp where name == "Doe").salary = (Emp where name == "Poe").salary;

czyli:
iDoe_salary = deref(iPoe_salary)

Dlatego przecież można napisać również
(Emp where name == "Doe").salary = 2000;

Podstawienie na obiekt złożony. Patrz przykład z książki strony 314 i 315
l-value - identyfikator obiektu złożonego
r-value - struktura z binderami.

Code:
(Emp where name == "Doe") = ("Poe" as name, 2000 as salary, ref(Dept where name == "Promotion) as works_in);


Code:
(Emp where name == "Doe") = (Emp where name == "Poe");



Podstawienie na obiekt pointerowy:
(Emp where name == "Noe").works_in = ref(Dept where name == "promotion");

l-value - identyfikator obiektu pointerowego o nazwie works_in
r-value - identyfikator obiektu działu
podstawienie
l-value = deref(r-value);

Musi być ref bo mielibyśmy dereferencję na obiekcie Dept i dostalibyśmy strukturę. A na obiekt pointerowy mamy podstawić referencję. ref jest flagą zawieszoną nad rezultatem zabraniającym wykonania dereferencji. Dzięki temu jako r-value w tym szczególnym wypadku nie otrzymujemy wartości tylko referencję.

Ergo:
Użytkownik musi mieć świadomość, że aktualizuje obiekt pointerowy.

stencel wrote:

Jakoś wydaje mi się to paskudne, bo na poziomie wywolan funkcji jest to samo, ale na jakimś meta-poziomie nie to samo.

Nie rozumiem. O jakie funkcje Ci chodzi?
stencel
Posted: Sunday, March 27, 2005 12:41:01 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
radamus wrote:
Nie rozumiem. O jakie funkcje Ci chodzi?


O funkcję ref ktora zawiesza te flage zabraniajaca dereferencji. Troche mi sie to wydaje dziwne, ale widze ze jest potrzebne przy tym ujeciu. Czy nie daloby sie tego jakos inaczej rozwiazac?

Moze odrebny operator przypisania, ktory nie wykonuje dereferencji rvalue, bylby tu jakims pomyslem? W sumie to tylko skladnia. A moze tak jak w wypadku rownosci, przy przypisaniu dodawac derefencje tylko wtedy, gdy jest to potrzebne?
radamus
Posted: Sunday, March 27, 2005 12:55:27 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
Ale sposób rozwiązania składni nie zmieni tego, że semantyka jest taka, że programista musi mieć świadomość tego, że podstawia na obiekt pointerowy.
Oczywiście cały czas pozostaje nie rozwiązany, a moim zdaniem istotny problem referencji do obiektu wirtualnego. Gdzieś tam w mojej prezentacji było na ten temat.
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.147 seconds.