Welcome Guest Search | Active Topics | Members | Log In

Konstruktory a on_new oraz parametryzacja perspektyw Options · View
habela
Posted: Wednesday, April 20, 2005 10:10:19 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
W tym wątku chciałbym podsumować i przedyskutować parę spostrzeżeń dotyczących tworzenia nowych obiektów wirtualnych i selekcji istniejących, a także (faktycznych lub pozornych) zbieżności z pojęciem konstruktora oraz z parametryzacją perspektyw.
Przypomnijmy te spostrzeżenia:
- Obiekt do określonej lokalizacji w bazie danych (powiedzmy - w obręb funkcjonowania odpowiedniej perspektywy) można (powinno być można) wprowadzić na kilka sposobów: utworzenie obiektu, wstawienie istniejącego obiektu czy zmiana nazwy istniejącego obiektu. Intencja wszędzie ta sama, ale czy sprowadzalne do pojedynczej implementacji (jedna procedura)?
- Języki obiektowe przyzwyczaiły nas do konstruktorów, które nie były chyba szerzej dyskutowane na gruncie Odry. Generalnie, zwłaszcza w obliczu hermetyzacji będą nam takowe chyba niezbędne.
- W dyskusji na temat wirtualnych wskaźników zaproponowałem szczególnego rodzaju parametryzowaną perspektywę, która pozwalałaby określać podzbiór (zwykle 1szt. acz niekoniecznie) obiektów danej perspektywy (celem wskazania obiektu docelowego, którego perspektywa nie jest zagnieżdżona w perspektywie wskaźnika ale występuje niezależnie). Tam istniało podobieństwo syntaktyczne do wołania konstruktora, bo: 1) wywoływane to było po nazwie interfejsu tej perspektywy docelowej. 2) przyjmowało parametry (które służyły tam do wyliczenia ziarna).

Myślę, że dla uporządkowania powyższego, trzeba wyodrębnić dwa "wymiary":
a) czy wyrażenie dodaje nowy obiekt, czy też służy wyselekcjonowaniu obiektu już oferowanego przez perspektywę?
b) czy dołączenie nowego obiektu przebiega poprzez dostarczenie gotowego obiektu, czy też poprzez podanie parametrów, które posłużą skonstruowaniu takiego.

Mogę tu zasygnalizować dwa problemy:
1) Parametryzacja perspektywy a konstruktor.
Wydaje się, że niestety mamy tu dwa zupełnie różne pojęcia, wymagające odrębnych implementacji. W parametryzowanej perspektywie potrzeba tylko tyle parametrów, aby zlokalizować właściwe ziarno w oparciu o istniejące dane. W wypadku konstruktora trzeba dostarczyć tyle parametrów, aby wystarczyły do dodania nowych danych do bazy.
2) Co do dyskutowanej operacji on_new, to łatwiejszą częścią wydaje się obsługa tworzenia nowych obiektów, poprzez podstawienie właśnie konstruktora. O tyle tylko specyficznego, że przywiązanego do określonej lokalizacji obiektów w bazie. Natomiast nie do końca widzę obsługę dołączenia istniejących obiektów. Niech taka operacja byłaby parametryzowana obiektem, który (za sprawą wstawienia lub zmiany nazwy) ma zostać objęty perspektywą. Pytanie brzmi - co z jego hermetyzacją? Jeśli założyć, że wymagalibyśmy od niego takiego samego interfejsu jak oferowany przez tę perspektywę, to pytanie czy zawierał on będzie dostatecznie dużo informacji dla skonstruowania obiektu wirtualnego...

Zapraszam do dyskusji.
radamus
Posted: Wednesday, April 20, 2005 12:24:02 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
W kwestii porównania procedur vitrual objects i konstruktorów (w ujęciu ogólnym a nie modeli składu SBA).
1. Konstruktor inicjalizuje obiekt (nie definuje go). Jest wywoływany po utworzeniu obiektu.
Procedura virtual objects definiuje obiekt wirtualny i "tworzy" kolekcję tych obiektów (seed'ów).

2. Przeciążanie kostruktora to, w najprostszym wypadku, parametryzacja tej inicjalizacji, czyli definiowanie różnych sposobów inicjalizacji. Dalej inicjalizujemy konkretny jeden obiekt.
Parametryzowane procedury virtual objects: wpływamy na liczbę seed'ów (wirtualnych obiektów).

3. Konstruktor jest wywoływany w sytuacji, gdy programista pisze instrukcję tworzącą obiekt, jest definiowany w klasie obiektu.
np.
Pracownik prac = new Pracownik("Kowalski");

Procedura virtual objects jest wykorzystywania w momencie gdy w zapytaniu używamy nazwy obiektu wirtualnego, jest definiowana w perspektywie.

Teraz SBA:
Instrukcja create (zgodnie z książką profesora):
Code:
create local|permanent ("Kowalski" as Nazwisko, 2000 as Pensja, ref(Dzial where Nazwa == "Marketing") as PracujeW) as Pracownik as member of PracownikClass;


Tworzymy nowy obiekt Pracownika i podłączamy go do klasy PracownikClass.

Cytat z książki profesora (długi ale kompletny):

Subieta w ObiektoweJęzykiZapytań wrote:
W niektórych systemach do utworzenia nowego obiektu używa się specjalnej metody o wyróżnionej nazwie, zwykle new. Metoda ta jest predefiniowana i parametryzowana nazwą klasy. Obiekt tworzony jest w tym samym środowisku, w którym taka metoda jest wywołana. Istnieje spora liczba różnych decyzji dotyczących tej metody, w szczególności:
- Metoda new może być predefiniowana i obligatoryjna dla każdej klasy, lub może być implementowana przez programistę na normalnych zasadach.
- Metoda new może tworzyć obiekt predefiniowany, zawsze taki sam, który następnie programista musi zainicjować, lub może być parametryzowana wartościami inicjalizującymi.
- Metoda new może korzystać z wartości domyślnych zapisanych wewnątrz klasy. Te wartości nie muszą być identyczne z wartościami domyślnymi dziedziczonymi przez obiekt w sytuacji, gdy brakuje mu pewnych atrybutów.

Wątpliwości budzi przypisanie metody new do klasy tworzonego obiektu. W modelach M1-M3 nie ma takiej możliwości, gdyż tam metody są inwariantami obiektów dziedziczonymi przez każdy obiekt tej klasy, natomiast metoda new nie może być w ten sposób dziedziczona. Zatem wprowadzenie metody new wiąże się z nowym modelem składu. Metoda new może być rozumiana jako metoda operująca na środowisku, w którym jest wywołana i posiadająca parametr w postaci klasy, lub odwrotnie, może być uważana za metodę należącą do meta-klasy (klasy, której instancjami są klasy) i parametryzowana lokalnym środowiskiem. W zależności od punktu widzenia własności semantyczne metody i jej użycia mogą być nieco inne. Inny punkt widzenia zakłada, że metoda ta należy do klasy potęgowej (power-set-of-class), tj. takiej klasy A, której instancjami są obiekty zawierające kolekcje obiektów klasy B. W takim przypadku metoda ta nie wnosi nic nowego i może być normalnie zdefiniowana przez programistę, o ile sobie tego życzy. Metoda ta w swoim wnętrzu musi wtedy używać któregoś z wariantów instrukcji create. W tej książce przyjmiemy ostatni punkt widzenia.


Pytanie jak tę kwestie przenieść na perspektywy.
1. Jaka byłaby składnia instrukcji create jeżeli Pracownik byłby obiektem wirtualnym.
2. Jaka byłaby semantyka tej instrukcji. Niewątpliwie musiałaby ona być przeciążona bo musimy zdefiniować semantykę tworzenia czegoś "wirtualnego" ( on_new | on_create ). Ale gdzie? Czy wewnątrz perspektywy Pracownika, czy może w środowisku przechowującym wirtualne obiekty pracownika? Jak ma się to tego on_insert?
3. Jaka byłaby możliwość parametryzacji takiego procesu tworzenia?

Pewnie urodzi się jeszcze wiele pytań, te na początek.
Podsumowując uważam, że problem parametryzacji procedury virtual objects jest niezależny od problemu tworzenia obiektu wirtualnego i wstawiania go do odpowiedniego środowiska.






habela
Posted: Thursday, April 21, 2005 7:43:13 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
We wczorajszej rozmowie Profesor przypomniał pierwote założenia procedury on_new w perspektywach. Ponieważ wkracza ona do działania w momencie, gdy gotowy obiekt jest już umieszczony w środowisku objętym perspektywą, to teraz wydaje mi się, że jednak mogłaby abstrahować od sposobu wprowadzenia, tzn. przykryć zarówno reakcję na create, jak też na wstawianie czy zmianę nazwy obiektu.
Co do konstruktorów, to faktycznie średnio nam pasują jako konstrukcja obowiązkowa która miałaby być wymagana dla wszystkich obiektów.
Nawiązałem do nich z dwóch powodów:
1. Odniesienie się do zauważonego przez Krzyśka podobieństwa (czysto syntaktycznego jednak) wołania parametryzowanej perspektywy do wołania konstruktora.
2. Problemu, jaki mam z sygnaturą procedury on_new w kontekście hermetyzacji i definicji interfejsów. Chodzi o to, że jeśli perspektywa spełnia interfejs A, to jeśli określę, że parametrem on_new byłaby referencja do obiektu zgodnego z interfejsem A, to czy rzeczywiście dane dostępne w takim interfejsie wystarczą na skonstruowanie obiektu wirtualnego.
radamus
Posted: Thursday, April 21, 2005 12:52:26 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
habela wrote:
We wczorajszej rozmowie Profesor przypomniał pierwote założenia procedury on_new w perspektywach. Ponieważ wkracza ona do działania w momencie, gdy gotowy obiekt jest już umieszczony w środowisku objętym perspektywą, to teraz wydaje mi się, że jednak mogłaby abstrahować od sposobu wprowadzenia, tzn. przykryć zarówno reakcję na create, jak też na wstawianie czy zmianę nazwy obiektu.

O, to mi trochę rozjaśniło.
Tylko co to znaczy gotowy obiekt?
Gotowy obiekt rzeczywisty czyli utworzony operacją create, posiadający rzeczywisty identyfikator. Ale czy my zakładamy, że w środowisku perspektywy (wirtualnego obiektu) może istnieć obiekt rzeczywisty?
Gotowy obiekt wirtualny, czyli jaki? Jak utworzony?

habela wrote:

2. Problemu, jaki mam z sygnaturą procedury on_new w kontekście hermetyzacji i definicji interfejsów. Chodzi o to, że jeśli perspektywa spełnia interfejs A, to jeśli określę, że parametrem on_new byłaby referencja do obiektu zgodnego z interfejsem A, to czy rzeczywiście dane dostępne w takim interfejsie wystarczą na skonstruowanie obiektu wirtualnego.


Tak może być ...
Przykład... Jedyne co mi się nasuwa w tej chwili to wirtualny pointer (podobny pokazywałem na seminarium). Składnia a'la perspektywy a nie interfejsy (jeszcze ich za dobrze nie czuję więc wolę tak).
Struktura a'la relacyjna:

Code:
class PracownikC {
    instance Pracownik;
    id: integer;
    nazwisko:string;
    pensja:integer;
   
}

class DzialC {
   instance Dzial;
   id:integer;
   nazwa::string;
   kierownik_id:integer;
}

class PracDzialC {
  instance PracDzial;
id:integer;
pracownik_id:integer;
dzial_id:integer;
}


Perspektywy definiujące wirtualne obiekty z pointerami.

Code:
view EmpDef {
virtual objects Emp { return Pracownik as p; }

   view NameDef {
         virtual objects name {return p.nazwisko as n;}
         //...
   }
   view SalaryDef{
          virtual objects sal { return p.pensja as pp; }
          //...
   }

  view WorksInDef[0..*] ref Dept {
         virtual objects worksIn { return (PracDzial where pracownik_id == p.id) as w; }
         on_navigate {return (Dept)(Dzial where id == w.dzial_id); }
         on_delete {delete w;}
         on_new(newDzialRef) {}
  }
}


view DeptDef
{
     virtual objects Dept {return Dzial as d;}
     
     view NameDef {
         virtual objects name {return d.nazwa as n;}
         //...
     }
     view NameDef {
         virtual objects name {return d.nazwa as n;}
         //...
     }
     view ManagedByDef ref Emp {
            virtual objects managedBy {return d.kierownik_id as m; }
            on_navigate { return (Emp)(Pracownik where id == m); }
        //  on_update(newManager) {//niemożliwe interfejs Emp nie ma wymaganych informacji}
     
     }
     view EmploysDef[0..*] ref Emp {
            virtual objects employs { return (PracDzial where dzial_id == d.id) as e; }
            on_navigate {return (Emp)(Pracownik where id == e.pracownik_id);}
            //on_insert(newWorksIn) {??}
     }


}


W definicjach wirtualnych pointerów (dokładnie w on_navigate) wykorzystałem operator rzutowania, który wcześniej proponowalem, czyli wywołanie procedury wirtual objects parametryzowane stanem ENVS.
Zwracam uwagę, że interfejsy wirtualne Emp i Dept nie uwzględniają id (pracowników i działów). Aby pointery można było aktualizować (na przykład zmienić kierownika działu) musielibyśmy w interfejsie Emp uwzględnić id pracownika. Jeżeli tego nie zrobimy to albo nie ma możliwości aktualizacji, albo potrzebne jest dojście "od kuchni" do seed'a wirtualnego obiektu.

Zastanawia mnie jeszcze tworzenia "gotowego obiektu", w tym wypadku obiektu pointerowego do wirtualnego obiektu Emp. Przykładowe zapytanie: Przypisz pracownika o nazwisku Doe do działu Public relations.

Code:
(Dept where name == "Public relations") :< create ref(Emp where name == "Doe") as worksIn;


Szczególnie interesuje mnie podzapytanie create ref(Emp where name == "Doe") as worksIn;

Czy ten operator create nie powinien być przeciążony? Jeżeli powinien to czy to jest on_new. Moim zdaniem to jest właśnie on_new czyli w moim rozumieniu konstruktor. Mówimy co to znaczy utworzyć obiekt wirtualny. A on_insert mówi co zrobić, gdy taki "gotowy" obiekt jest wstawiany do środowiska perspektywy. W tym przykładzie nawet poszedłbym dalej i powiedział, że jest to on_new_reference w perspektywie Emp powiązane z on_insert w perspektywie definiującej wirtualny pointer worksIn. Jeżeli tak byśmy założyli to można byłoby odpowiednie definicje napisać na przykład tak:

Code:
view EmpDef {
virtual objects Emp { return Pracownik as p; }
on_new_reference { create ref(p); } //referencja do Emp jest referencją do Pracownik
  //...
}

view DeptDef
{
     virtual objects Dept {return Dzial as d;}

      //...
     
     view EmploysDef[0..*] ref Emp {
            virtual objects employs { return (PracDzial where dzial_id == d.id) as e; }
            on_navigate {return (Emp)(Pracownik where id == e.pracownik_id);}
            on_insert(newWorksIn) { //newWorksIn tak naprawdę jest referencją do obiektu Pracownik
                                                  // a nie wirtualnego Emp
                                                  create (/*unikatoweID as id*/, deref(d.id) as dzial_id,
                                                             deref(newWorksIn.Pracownik.id) as pracownik_id)
                                                              as PracDzial as member of PracDzialC;
                                                  delete newWorksIn; //już niepotrzebne
                                               }
     }


}


Oczywiście to rozwiązanie zakłada, że implementacje Emp i Dept są pisane przez programistów, którzy nawzajem wiedzieli o swojej pracy i wcześniej ustalili między sobą szczegóły implementacji. Co mi się nie podoba.

Z on_new jest gorzej:
Code:
create ("Poe" as name, 2000 as sal) as Emp as member of ??;


Jeżeli chcielibyśmy przeciążyć tę definicję w perspektywie parametrem create musiałby być identyfikator wirtualny.
Albo to coś po as member of wskazywałoby na miejsce skąd należy wywołać on_new . Czyli mogłaby to być definicja perspektywy (EmpDef).
Code:
create ("Poe" as name, 2000 as sal) as Emp as member of EmpDef;

Tylko semantyka as member of mi się wtedy zmienia. Bo musiałaby wtedy uwzględniać to, że to jest perspektywa: zamiast wywoływać zwykłe create a potem utworzony obiekt podłączać do odpowiedniej klasy musi wywołać procedurę on_new z perspektywy:


Code:
view EmpDef {
virtual objects Emp { return Pracownik as p; }
on_new(newEmp) { return (Emp) (create (/*unikatowe id*/ as id,
                              deref(Emp.name) as Nazwisko,
                              deref(Emp.sal) as pensja) as Pracownik as member of PracownikC);
                            }
  //...
}


Znowy mamy rzutowanie bo zakładamy, że wynikiem create będzie wirtualny identyfikator. W on_new_reference tak nie założyłem bo inaczej nie mógłbym potem wstawić do Dept.
Rozmyślnie pominąłem przy tworzeniu obiektu od razu inicjalizowanie pointera bo musiałby jeszcze zdefiniować on_new_reference w DeptDef.

Zastrzegam, że są to tylko moje luźne rozważania, które wyprodukowały coś dosyć skomplikowanego co po prostu ma być przyczynkiem do dalszej dyskusji.
subieta
Posted: Friday, April 22, 2005 5:53:41 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
radamus wrote:

Tylko co to znaczy gotowy obiekt?
Gotowy obiekt rzeczywisty czyli utworzony operacją create, posiadający rzeczywisty identyfikator. Ale czy my zakładamy, że w środowisku perspektywy (wirtualnego obiektu) może istnieć obiekt rzeczywisty?
Gotowy obiekt wirtualny, czyli jaki? Jak utworzony?


Obiekty wirtualne nazwane X tworzone są w pewnym środowisku przez perspektywe XDef, ktora siedzi w tym samym środowisku. Np. w środowisku bazy danych. Teraz ktoś próbuje utworzyć (albo wstawic) w tym samym środowisku obiekt rzeczywisty nazwany X. Dotychczas nie było istotnych przeciwskazań, aby tego uzytkownik nie mogł zrobic. Teraz jest inaczej. W takiej sytuacji interpreter rozpoznaje, że pojawił się obiekt rzeczywisty X w środowisku, w którym są obiekty wirtualne nazwane X. Po rozpoznaniu takiej sytuacji interpreter wywołuje procedure on_new ze środka perspektywy XDef. Intencją tego wywolania jest to, aby obiekt rzeczywisty X został zamieniony na obiekt wirtualny X. Procedura on_new ma wiec obiekt rzeczywisty X jako parametr i poprawia rzeczywistą bazę danych tak, aby wytworzyc dodatkowy obiekt wirtualny X, ktory jest identyczny z rzeczywistym obiektem X. Po dokonaniu tego likwiduje rzeczywisty obiekt X.

Rzeczywisty obiekt X nie jest wstawiany do środka wirtualnego, ale obok obiektów wirtualnych X. Zadaniem on_new jest zamiana tego rzeczywistego obiektu na identyczny wirtualny. Przyjmujemy wiec zalozenie, że chwilowo moga istniec obiekty rzeczywiste i obiekty wirtualne nazwane tak samo, ale na koniec tej operacji takie współistnienie jest niemozliwe: o ile w danym srodowisku istnieją obiekty wirtualne nazwane X (nawet jeżeli ich zbiór jest chwilowo pusty), to w tym samym srodowisku wszystkie rzeczywiste obiekty nazwane X sa automatycznie zamieniane na obiekty wirtualne nazwane X.

Mam nadzieje, ze teraz bedzie jasniej.
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.102 seconds.