Welcome Guest Search | Active Topics | Members | Log In

Views: Procedura on_new a moduły oraz zmieniony on_insert Options · View
habela
Posted: Saturday, February 12, 2005 9:53:45 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Z 3-stronicowego ekstraktu od Hanki dotyczącego propozycji nowej operacji on_new, można się dowiedzieć m.in. następujących szczegółów:
1. dążąc do pełnej przezroczystości, dla obiektów zarówno konkretnych jak i wirtualnych, przyjmuje się stosowalność do nich tych samych poleceń tworzenia:
Code:
create [ local | global ] query

2. zakłada się, że polecenie takie zdeterminuje lokalizację w bazie danych, w której ma być utworzony taki obiekt. Wobec tego, w sytuacji, gdy w zadanym miejscu istnieje perspektywa dla obiektów wirtualnych o odpowiadającej tworzonemu nazwie, zamiast utworzyć obiekt konkretny - zostanie wykonane zachowanie wyspecyfikowane w ramach operacji on_new.
3. wspomniano, że zachowanie on_new nie może się ograniczyć tylko do reakcji na odpowiednie polecenie create. Trzeba mianowicie również reagować na wstawianie (insert!) obiektu konkretnego w objętą perspektywą własność bazy danych. Obiekt musiałby być skonwertowany na odpowiednią reprezentację wirtualną. Podobnie należy uczynić w wypadku zmiany nazwy obiektu, która to zmiana czyni go zgodnym z definicją perspektywy.
4. jak dotychczas, definicja perspektywy jest "zakotwiczona" w konkretnym miejscu bazy danych: zarówno w sensie konkretnego miejsca występowania obiektów wirtualnych jak i w sensie lokalizacji obiektów źródłowych, na których dane wirtualne się opierają.

Mam wobec tego następujące spostrzeżenia:
Być może nie w pełni wyczuwam specyfikę rozwiązania samego polecenia create. Języki programowania a także bazy takie jak Objectivity przyzwyczaiły nas do innego trybu postępowania - np.: a) utworzenie obiektu ulotnego; b) wstawienie go do określonego miejsca w bazie danych, co spowoduje jego utrwalenie. Czyli dwa osobne polecenia. Tutaj create łączy w sobie te dwa zadania, toteż wymaga większej liczby różnych opcji (zob. niżej).
Ad. 1. Interpretację local i global trzeba uszczegółowić (a może rozwinąć postać polecenia?) dla uwzględnienia sprawy modułów (przypomnijmy, że w oparciu o ostatnie założenia - służących zarówno organizacji kodu jak i przechowywaniu obiektów bazy). Trzeba zatem ustalić, co oznacza create global a co create local uruchomione wewnątrz procedury (lub metody należącej do klasy) znajdującej się w określonym module.
Ad. 2. Zachowanie operacji on_new nie jest zatem uruchamiane zawsze, gdy powstanie obiekt o zgodnej nazwie czy budowie z definicją perspektywy, ale tylko wówczas, gdy wpierw inne mechanizmy bazy ustalą, gdzie ten obiekt ma zostać utworzony i stwierdzą, że to akruat miejsce jest przykryte perspektywą (tj. istnieje tam odpowiednia virtual feature).
Ad. 3. Tutaj mała dygresja związana z dyskusjami nad operacją on_insert. Będę się starał wyjaśnić, dlaczego przy obecnym stanie rzeczy wyczuwam tu nadmiarowość.
Oryginalnie on_insert zdefiniowany dla perspektywy, która serwowała obiekty wirtualne A obsługiwał (ta sama operacja) wstawienia do obiektu A innych podobiektów - potencjalnie różnych: B, C, D. Przyznam, że nie całkiem mi się to podobało, gdyż:
- ta sama operacja on_insert w obiekcie A mogła wymagać warunkowych elementów kodu, służących (najprawdopodobniej zróżnicowanej) obsłudze wstawień obiektów B, C, D (estetyka i pielęgnacyjność);
- zakładając, że obiekt wirtualny D znajdujący się w obiekcie A byłby obiektem prostym, definiowanie operacji on_insert dla jego (pod)perspektywy nie ma racji bytu;
- z kolei, zakładając że obiekty wirtualne A występują na górnym poziomie bazy danych (czy modułu), to potrzebny jest nad nimi jakiś twór nadrzędny (właśnie baza cz moduł), który byłby właścicielem operacji on_insert, definiującej sposoby wstawiania wszystkich "globalnych" obiektów wirtualnych (zastrzeżenia - jak wyżej plus konieczność istnienia tej spec-perspektywy górnego poziomu, specjalnie dla samego tylko tego jednego on_insert) [być może właśnie ten problem był motywacją do zaproponowania on_new]
Dodatkowym argumentem by rozważyć przesunięcie zakresu odpowiedzialności on_insert poziom wyżej było dla mnie dążenie do ujednolicenia sposobu specyfikacji interfejsów (z podaniem, które operacje generyczne są dla danej własności dostępne, a które nie), z definicją implementacji tych operacji (tak, by flaga stwierdzająca w interfejsie, że coś jest wstawialne odpowiadała nazwie operacji generycznej w perspektywie, która obsługuje to wstawienie).
Jedynym problemem, który w tym zauważyłem byłyby szczególne sytuacje, w których definicja perspektywy obiektów A mogłaby serwować w obiektach A podobiekty B, C i D bez konieczności definiowania dlań podperspektyw (nie byłoby wtedy gdzie umieścić operacji opisującej co robić przy wstawianiu np. obiektu B. Ale nie jestem pewien, czy w ogóle dopuszczamy takie perspektywy i jak by się to miało do definicji schematu.
W każdym razie, tak zmieniona interpretacja on_insert ujawnia już wyraźnie bardzo daleko idące podobieństwo (zapewne - nadmiarowość) tych dwóch operacji (insert i new).
Ad. 4. Gdyby perspektywa była bardziej "przenośna" w sensie jej lokalizacji w bazie danych, tzn. gdyby bardziej przypominała klasę, nie zaś własonść zdefiniowaną w konkretnym miejscu w oparciu o klasę, te dwie różne operacje miałyby rację bytu. Gdy zaś on_new ma na dobrą sprawę oznaczać on_insert_new, wydaje się to nadmarowe.

Podsumowując - przy moim obecnym stanie rozumienia problemu, sugerowałbym albo poprzestanie na zmienionym (jak wyżej opisano) on_insert, albo zastąpienie go odpowiednio uogólnionym (a może nawet nie trzeba nic już uogólniać?) on_new.
KK
Posted: Saturday, February 12, 2005 1:41:36 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
Odnośnie nowego on_insert:
habela wrote:
Jedynym problemem, który w tym zauważyłem byłyby szczególne sytuacje, w których definicja perspektywy obiektów A mogłaby serwować w obiektach A podobiekty B, C i D bez konieczności definiowania dlań podperspektyw (nie byłoby wtedy gdzie umieścić operacji opisującej co robić przy wstawianiu np. obiektu B. Ale nie jestem pewien, czy w ogóle dopuszczamy takie perspektywy i jak by się to miało do definicji schematu.


Wydaje mi się, że rarówno w pracy Hani, jak i prototypi Radka takie podobiekty B, C, D MUSZĄ mieć swoje podperspektywy.

habela wrote:

Ad. 4. Gdyby perspektywa była bardziej "przenośna" w sensie jej lokalizacji w bazie danych, tzn. gdyby bardziej przypominała klasę, nie zaś własonść zdefiniowaną w konkretnym miejscu w oparciu o klasę, te dwie różne operacje miałyby rację bytu. Gdy zaś on_new ma na dobrą sprawę oznaczać on_insert_new, wydaje się to nadmarowe.


Właśnie ostatnio o to pytałem:
Czy w nowym podejściu z interfejsami zakładamy że perspektywa może być zdefiniowana w jednym miejscu (jakimś globalnym), definiując sposób tworzenia powiedzmy BogategoPracowanika a potem użyta w kilku konkretnych miejscach jako VirtualFeatures?
Choć nie wiem czy w takiej sytuacji trzeba by rozróżniać on_new i nowego on_insert.

stencel
Posted: Saturday, February 12, 2005 6:11:42 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Musze powiedziec, ze w pelni popieram koncepcje Piotra, czyli w mamy cztery generyczne operacje na perspektywie (on_retrive, on_delete, on_update i on_insert), przy czym on_insert opisuje, co sie dzieje przy utworzeniu nowego obietu wirtualnego generowanego przez te perspektywe. Oto swietne argumenty za (powtorzone za Piotrem, ale krotko):

Wstawienie obiektu wirtualnego B do obiektu wirtualnego A powinno odbywać sie przez on_insert podperspektywy B perspektywy A.
A nie tak jak "u Hanki" poprzez on_insert na perspektywie A.
Dzieki propozycji Piotra nie ma potrzeby tworzenia top-perspektywy do tworzenia top-obiektow wirtualnych.
A nie tak jak "u Hanki", gdy jest taka top-perspektywa potrzebna.
On_insert nie wymaga kodu wariantowego.
A nie tak jak "u Hanki", gdy w on_insert trzeba sprawdzic, czy wstawiono obiekt B, C czy D.

Obecnie nie widze argumentow przeciw. Jesli ktos je ma, niech podaje, albo zamilknie na wieki.

Zwlaszcza Szefa o to prosze, bo on jednak patrzy znacznie dalej ni my i moze widziec rzeczy, ktore nam sie przeoczylo.
subieta
Posted: Sunday, February 13, 2005 11:42:28 AM

Rank: Advanced Member

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

Zwlaszcza Szefa o to prosze, bo on jednak patrzy znacznie dalej ni my i moze widziec rzeczy, ktore nam sie przeoczylo.

Protestuje. Nie mam zadnego monopolu na racje i moje widzenie jest skrzywione implementacjami, w ktorych popelnilem straszna mase bledow. Na swoje usprawiedliwienie mam to, ze nie ma nauki bez bledow. Bledow nie popelniaja tylko teoretycy informatyki, poniewaz nigdy nie probuja implementowac, wiec pozostaja w rozkosznej pewnosci siebie bycia genialnie nieomylnymi. "The trouble with the world is that the stupid are cocksure and the intelligent full of doubt." (Bertrand Russell)

Wracajac do tematu. wydaje sie, ze dyskusja troche uciekla w strone dyskusji syntaktycznej, tj. czy bedzie on_insert ze zmieniana semantyka, czy tez pozostawimy stare on_insert i wprowadzimy jeszcze on_new. Aby troche te dyskusje uporzadkowac, trzeba wrocic do zrodel. Zacznijmy od tego, z jakim zestawem instrukcji imperatywnych mamy do czynienia w przypadku obiektow materialnych. Ten zestaw jest oczywiscie arbitralny, mozna byloby wymyslec inny, ale moje skrzywienie implementacyjne kazalo mi wprowadzic nastepujace instrukcje:
- podstwawienie (:=)
- usuwanie (delete)
- wstawianie (insert)
- tworzenie (create)
- zmiana nazwy (rename).
Instrukcja create jest parametryzowana miejscem, ktore moze byc local lub global i zgadzam sie z Piotrem, ze ta parametryzacja moze byc redundantna. Sprawa gustu i wyczucia, wiec nie mam tu nic ani za ani przeciw. Natomiast samo create zawsze bedzie potrzebne, i jest niewazne, ze np. bedzie nazywac sie new i bedzie parametryzowane by defaults.

To co jest istotne to wlasnosc perspektyw zwana transparency. Transparency ma byc pelna, tj. przede wszystkim brak roznic syntaktycznych i pragmatycznych. Zalozmy, ze mamy pewne srodowisko zawierajace wirtualne obiekty A. Jest nieistotne, czy jest to srodowisko lokalne pewnej procedury, czy srodowisko sesji uzytkownika, czy srodowisko globalne bazy danych. Jezeli uzytkownik ma nie miec zadnych roznic syntaktycznych i pragmatycznych, to powinien miec mozliwosc utworzenia w tym srodowisku nowych obiektow A uzywajac TYCH SAMYCH opcji, ktore zastosowalby, gdyby obiekty A byly zmaterializowane. Moze wiec uzyc opcji create i nie jest wlasciwe twierdzenie, ze przeciez moglby to zrobic gdzies na boku lokalnie a pozniej zastosowac insert. Zmuszanie go do zmiany stylu pracy i wykonywania innego zestawu instrukcji oznacza wlasnie brak transparency od strony pragmatyki.

Tymczasem z create (rowniez z rename) jest problem, bo dotychczasowe instrukcje aktualizacji obiektow wirtualnych dzialaly na wirtualnych identyfikatorach, a tutaj takich identyfikatorow nie ma. Zaproponowalem wiec p.Hani pewne rozwiazanie w tym zakresie, ktore wlasnie bylo czyms w rodzaju zakamuflowanego insert, ale kiedy to zobaczylem w jej pracy doktorskiej, przestalo mi sie podobac. Nie bede szczegolowo pisal jak to bylo rozwiazane i dlaczego przestalo mi sie podobac, glownym problemem byla ograniczona przezroczystosc. Wypracowana w koncu metoda jest banalnie prosta i dokladnie w duchu dotychczasowego podejscia do wirtualnych perspektyw. Mianowicie, jezeli w dowolny srodowisku sa obiekty wirtualne, to srodowisko takie posiada ich rejestr zawierajacy nazwy obiektow wirtualnych skojarzone z identyfikatorami definicji tych perspektyw. Zalozmy, ze w tym rejestrze sa nazwy A. Proba utworzenia obiektu A (jakakolwiek, rowniez przez rename lub insert) w tym srodowisku (inne nas nie obchodza) powoduje, ze takie obiekty rzeczywiscie fizycznie sie utworza. Ale tylko na chwile, bo za chwile interpreter stwierdzi, ze A jest w rejestrze obiektow wirtualnych, wobec czego wywola procedure on_new z wnetrza odpowiedniej perspektywy, komunikujac jej identyfikator tego utworzonego obiektu jako parametr. Ta procedura zrobi co zechce, a na koncu zlikwiduje zakomunikowany jej obiekt A. Programista piszacy procedure on_new bedzie o tym wiedzial, wiec napisze te procedure w taki sposob, aby powstal wirtualny obiekt A, ktory zastapi zmaterializowany obiekt A. Jak to zrobi, to jego sprawa, nie bedziemy sie do tego wtracac (i obawiam sie, nie mamy takiej mozliwosci).

Powstaje oczywiscie problem, czy to nie jest redundantne. Jezeli create dzialalaby tylko w lokalnym srodowisku, to w zasadzie problemu by nie bylo (nie musimy w lokalnym srodowisku tworzyc obiekty wirtualne). Powstalby natomiast ten sam problem z rename oraz insert. Insert materialnego obiektu A do MATERIALNEGO srodowiska B, w ktorym bylyby wirtualne obiekty A, nie spowodowalby uruchomienia jakichkolwiek procedur przeciazajacych, gdyz srodowisko B jest materialne. Powstaloby wiec srodowisko, w ktorym bylyby zarowno materialne jak i wirtualne obiekty A, a to zaowocowaloby niespojnoscia na stosie (rozne sekcje), nie mowiac o zamieszaniu koncepcyjnym. Trzeba wiec te materialne obiekty A zamienic na wirtualne, i wracamy do punktu wyjscia, czyli poprawienie definicji wirtualnych obiektow A w taki sposob, aby wszystko gralo. Opisany sposob jest jak dotad dla mnie najbardziej uniwersalny, prosty w implementacji i zapewniajacy 100% przezroczystosci. Inny sposob moim zdaniem bylby mozliwy tylko po zasadniczym przebudowaniu zestawu operatorow aktualizacyjncyh dzialajacych na obiektach zmaterializowanych.
stencel
Posted: Sunday, February 13, 2005 10:50:10 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
No to ja chce to ujac tak. Na obiektach materialnych mamy piec operacji: :=, delete, insert, create, rename. Tylez wiec powinnismy miec na obiektach wirtualnych. I naturalnym jest zeby te operacje na obiektach wirtualnych A definiowac razem z definicja obiektow wirtualnych A (ich perspektywa). Takiemu argumentowi nie mozna nic zarzucic.

Tylko troche dyskomfortowym wydaje sie, ze w definicji np:

Code:
export Person {
    name : string retrieve, update;
    phoneNo : string [0..*] insert, delete;
}


Slowko insert oznacza tu, ze na obiekcie spelniajacym eksport "Person" mozna wykonac insert obiektu phoneNo, podczas gdy tuz obok slowko delete oznacza ze mozna wykonac delete na obiekcie phoneNo. Slowo insert choc wystepuje na tym samym poziomie skladniowym co delete dotyczy w istocie operacji o poziom wyzej.

Co mozemy z tym zrobic? Na razie widze trzy mozliwosci:

1. Mozemy z tym zyc, bo to nie jest problem.
2. Skladnia, ktora opracowalismy, jest wadliwa w tym wzgledzie i nalezy ja poprawic.
3. Semantyka lezacego pod tym wszystkim mechanizmu perspektyw jest zla (piec operacji, o ktorych mowa na poczatku mojego postu).

Ktora mozliwosc jest najblizsza prawdy? A moze jest jeszcze czwarta, ktorej tu nie widze?
habela
Posted: Sunday, February 13, 2005 11:08:57 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Co do wspomnianej wcześniej pragmatyki, to jak zaznaczałem - nie mam tu dobrego wyczucia, bo ja wzorem popularnych języków przywykłem do takiego właśnie 2-krokowego umieszczania obiektów w składzie, więc moje sugestie pozostawały pod takim wpływem.
Nie całkiem zrozumiałem problem podniesiony w tym akapicie:
subieta wrote:
Powstaje oczywiscie problem, czy to nie jest redundantne. Jezeli create dzialalaby tylko w lokalnym srodowisku, to w zasadzie problemu by nie bylo (nie musimy w lokalnym srodowisku tworzyc obiekty wirtualne). Powstalby natomiast ten sam problem z rename oraz insert. Insert materialnego obiektu A do MATERIALNEGO srodowiska B, w ktorym bylyby wirtualne obiekty A, nie spowodowalby uruchomienia jakichkolwiek procedur przeciazajacych, gdyz srodowisko B jest materialne. Powstaloby wiec srodowisko, w ktorym bylyby zarowno materialne jak i wirtualne obiekty A, a to zaowocowaloby niespojnoscia na stosie (rozne sekcje), nie mowiac o zamieszaniu koncepcyjnym. Trzeba wiec te materialne obiekty A zamienic na wirtualne, i wracamy do punktu wyjscia, czyli poprawienie definicji wirtualnych obiektow A w taki sposob, aby wszystko gralo. Opisany sposob jest jak dotad dla mnie najbardziej uniwersalny, prosty w implementacji i zapewniajacy 100% przezroczystosci. Inny sposob moim zdaniem bylby mozliwy tylko po zasadniczym przebudowaniu zestawu operatorow aktualizacyjncyh dzialajacych na obiektach zmaterializowanych.

Oczywiście zgadzam się, że należy (choćby z samych tylko względów czytelności dla programisty) zabronić współistnienia w tej samej lokalizacji zarówno obiektów wirtualnych jak i konkretnych o tej samej nazwie. Nie zrozumiałem tutaj, co wzbrania nam takiego zaimplementowania mechanizmu, który dokonywałby konwersji wszelkich umieszczanych tam w taki czy inny sposób obiektów A o ile w danym środowisku obowiązuje odpowiednia definicja perspektywy.
Zapytam inaczej: po co nam zmieniony lub tradycyjny on_insert, jeśli zdecydujemy się na wprowadzenie on_new, które stoi na straży wszystkich możliwych sposobów wprowadzenia do danego środowiska obiektów A (tj. reaguje na insert, create podpadający pod dane środowisko a także rename)? Tzn.: mniejsza o nazwy - czy nie da się tego przykryć 4 tylko operacjami?
subieta
Posted: Monday, February 14, 2005 9:56:12 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
habela wrote:
Zapytam inaczej: po co nam zmieniony lub tradycyjny on_insert, jeśli zdecydujemy się na wprowadzenie on_new, które stoi na straży wszystkich możliwych sposobów wprowadzenia do danego środowiska obiektów A (tj. reaguje na insert, create podpadający pod dane środowisko a także rename)? Tzn.: mniejsza o nazwy - czy nie da się tego przykryć 4 tylko operacjami?

Tradycyjny insert dla obiektow zmaterializowanych wstawia pewien obiekt do srodka innego obiektu. Taki sam, bez zmienionej semantyki i pragmatyki, powinien byc dla obiektow wirtualnych, inaczej przezorczystosc pragmatyki bedzie niepelna. Operator create dla obiektow zmaterializowanych mial inna semantyke: najpierw tworzyl obiekt, a pozniej robil insert do pewnego srodowiska. Zatem insert i create nie sa syntaktycznie, semantycznie i pragmatycznie rownowazne dla obiektow materialnych i obawiam sie, ze trudno bedzie z ktoregos z nich zrezygnowac na rzecz innego.Co za tym idzie, ich odpowiedniki dla obiektow wirtualnych rowniez nie moga byc tym samym. Mozna by powiedziec tak: on_insert wstawia obiekt materialny bedacy jego parametrem do srodka obiektu wirtualnego, podczas gdy on_new wstawia obiekt materialny bedacy jego parametrem obok istniejacych obiektow wirtualnych. Oczywiscie to drugie "wstawia" oznacza wytworzenie nowego obiektu wirtualnego, ktory zastapi obiekt zmaterializowany bedacy parametrem on_new.

Zgadzam sie natomiast, ze calosc jest dosc splatana i moze byc trudna do objasnienia dla programistow. Tym bardziej, ze w SQL insert oznacza wstawianie "obok" a nie wstawianie "do srodka". Obawiam sie, ze spekulacje na sucho dadza w tym wzgledzie niewielki postep, trzeba to zaimplementowac i zobaczyc jak wyszlo, przede wszystkim od strony syntaktycznej.

Jezeli chodzi o opis na poziomie interfejsow (poprzedni post Krzyska) to uwazam, ze slowko insert powinno pojawic sie tam, gdzie mozna cos wstawic "do srodka", zas slowko create (albo new) tam, gdzie mozna cos wstawic "obok".
stencel
Posted: Monday, February 14, 2005 1:56:51 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
No jasne! Eureka!

Mamy dwie operacje insert i create, ktore roznia sie dzialaniem, ale sa nierozroznialne z punktu widzenia interfejsu!

Powtorze kod deklaracji:

Code:
export Person {
    name : string retrieve, update;
    phoneNo : string [0..*] insert, delete;
}


Slowko insert oznacza, ze w srodku eksportu Person moze byc obiekt (lub feature tak jak lubi Piotr). Ze jest to dozwolone. Natomiast na poziomie interfejsu nie obchodzi nas, czy na poziomie implementacji dodanie obiektu phoneNo odbedzie sie poprzez on_insert na Person, czy on_create na phoneNo. W interfejsie insert oznacza ze da sie to zrobic i implementator ma to zapewnic, a jak? To juz jego sprawa.

Jest wiec rozwiazanie czwarte, ktorego nie widzialem wczesniej. Tertium non datur, ale nikt nic nie powiedzial o quartum ;)
subieta
Posted: Monday, February 14, 2005 6:50:08 PM

Rank: Advanced Member

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

Code:
export Person {
    name : string retrieve, update;
    phoneNo : string [0..*] insert, delete;
}


Slowko insert oznacza, ze w srodku eksportu Person moze byc obiekt (lub feature tak jak lubi Piotr). Ze jest to dozwolone. Natomiast na poziomie interfejsu nie obchodzi nas, czy na poziomie implementacji dodanie obiektu phoneNo odbedzie sie poprzez on_insert na Person, czy on_create na phoneNo. W interfejsie insert oznacza ze da sie to zrobic i implementator ma to zapewnic, a jak? To juz jego sprawa.


Nie wiem, czy zostalem dobrze zrozumiany. Ja w takim przypadku napisalbym raczej:
Code:
export Person {
    name : string retrieve, update;
    phoneNo : string [0..*] retrieve, create, delete;
} insert phoneNo;


Oznaczaloby to: wolno mi utworzyc nowy phoneNo przy pomocy instrukcji create. Wolno mi takze wlozyc do srodka obiektu Person nowy obiekt phoneNo przy pomocy instrukcji insert.
To byla moja intencja, ale nie wiem czy pasuje do obecnej dyskusji nad sprawa interfejsow, czy jest spojna i czy nie jest redundantna.
subieta
Posted: Monday, February 14, 2005 7:06:45 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Przemyslalem jeszcze raz i doszedlem do wniosku, ze propozycja Krzyska jest OK. Nie ma sensu na poziomie interferfejsu rozrozniac create i insert.
habela
Posted: Wednesday, April 20, 2005 10:12:04 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Konkluzja powyżej dotyczy dodawania nowych obiektów z punktu widzenia interfejsu. (Istotnie, byłoby sztuczne, aby jednen z równoważnych dla obiektów zmaterializowanych sposobów dodawania nowej instancji był dozwolony a inny nie.
Czy jednak uda się w podobny sposób ujednolicić - tj. przykryć jedną operacją - definicję (implementację) dodawania takich nowych obiektów?
Ponieważ zbiegło się to nieco z dyskusją na temat parametryzacji perspektyw - proponuję dla czytelności podjęcie powyższego problemu w osobnym wątku:
http://iolab.pjwstk.edu.pl:8081/forum/Default.aspx?g=posts&t=67
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.169 seconds.