hume@buckwheat.sps.mot.com (Chris Hume) (10/20/89)
A shortcoming current Object Oriented Languages seem to have, is that they all seem to assume a single and more or less static class structure with respect to existing instances. In an Object Oriented Data Base, one might wish to take more of a "Hyper Text" approach and alter the existing class structure or add alternative "views". Then it should be possible to define methods for, and interact with, existing instances with respect to any of these dynamic frames of reference while keeping these frames of reference safe from interference by the others. In order for this to work, some mechanism would have to be devised allowing new or modified classes to identify the existing instances that belong to these classes. This would make use of class structure more closely resemble the way we usually build conceptual structure. We do not simply track subsequent instances after generating new concepts. We often map new conceptual structure onto previous experience. Dynamic Classes would be especially valuable in a Data Bases where there is large investment in acquisition (or generation) of the data. Chris -- Phone: (602) 994-6835 EMail: hume@sps.mot.com
Reply-To:@brutus.cs.uiuc.edu (10/20/89)
hume@buckwheat.sps.mot.com (Chris Hume) writes: >A shortcoming current Object Oriented Languages seem to have, >is that they all seem to assume a single and more or less static >class structure with respect to existing instances. In an Object >Oriented Data Base, one might wish to take more of a "Hyper Text" >approach and alter the existing class structure or add alternative >"views". Then it should be possible to define methods for, and >interact with, existing instances with respect to any of these >dynamic frames of reference while keeping these frames of reference >safe from interference by the others. This is an interesting concept, but it has at least one hidden assumption: you assume a class is extensional, i.e. a class acts as a container for all its instances like a relation does for its tuples. This is not true for all OODBMSs. In these, you create collection objects to hold either the instances or references to the instances. However, this might actually simplify the job. In one of these databases, you could add all instances of a class to a particular collection object that has methods for filtering access to its members. To handle "interference" you'd have to decide whether updates are allowed to the members of the view or whether they are read-only. If updates are allowed, you would then have to decide whether they are local to the view or not. If they are local, then you could create each view by replicating the base collection. This would screen off your changes to the view from the base collection, but it would also screen off changes to the base collection from the view. To get updates to the base collection propagated to the view, you could create the view by copying references to the objects rather than the objects themselves. If you still want your changes to be local, you could implement a copy-on-write mechanism in the update methods. To make the views "dynamic", you would define the view class and then instantiate a view with a particular base collection as a parameter to the constructor. >In order for this to work, some mechanism would have to be devised >allowing new or modified classes to identify the existing instances >that belong to these classes. This is already in those OODBMSs that support dynamic schema evolution, like ORION, Iris, and Sherpa. (Obligatory references below.) >This would make use of class structure more closely resemble the >way we usually build conceptual structure. We do not simply track >subsequent instances after generating new concepts. We often map >new conceptual structure onto previous experience. >Dynamic Classes would be especially valuable in a Data Bases where >there is large investment in acquisition (or generation) of the data. Yeah, but it can be major league hairy to implement. hal. @article{orion-schema-evol, keywords=":orion:oo:dbms:schema evol:", title="Semantics and Implementation of Schema Evolution in Object-Oriented Databases", author="Jay Banerjee and Won Kim and Hyoung-Joo Kim and Henry F. Korth", journal=sigmod, volume="16", number="3", month= dec, year=1987, pages="311--322"} @inproceedings{qingli, keywords=":oo:dbms:schema evol:", title="Object Flavor Evolution in an Object-Oriented Database System", author="Qing Li and Dennis McLeod", booktitle="Conference on Office Information Systems", editor="Robert B. Allen", address="Palo Alto, California", month= mar, year="1988", pages="265--275"} @techreport{sherpa, keywords=":sherpa:oo:dbms:schema evol:survey:", title="Schema Evolution in Object-Oriented Database Systems", author="Gia-toan Nguyen and Dominique Rieu", institution="Unite De Recherche, INRIA-Rocquencourt", number="947", month= dec, year="1988"}
alms@cambridge.apple.com (Andrew L. M. Shalit) (10/24/89)
In article <HUME.89Oct19162731@buckwheat.sps.mot.com> hume@buckwheat.sps.mot.com (Chris Hume) writes:
A shortcoming current Object Oriented Languages seem to have,
is that they all seem to assume a single and more or less static
class structure with respect to existing instances.
I'm surprised no one has responded to this yet. CLOS doesn't
assume a static system. Classes can be redefined, and there
is a full protocol for updating existing instances. This is
possible because object system support exists at run time, not
just at compile time.
-andrewhallett@positron.uucp (Jeff Hallett x5163 ) (10/24/89)
In article <ALMS.89Oct23180936@brazil.cambridge.apple.com> alms@cambridge.apple.com (Andrew L. M. Shalit) writes: > >I'm surprised no one has responded to this yet. CLOS doesn't >assume a static system. Classes can be redefined, and there >is a full protocol for updating existing instances. This is >possible because object system support exists at run time, not >just at compile time. I cross-post this because people may be able to answer the follow-up that are on different groups. I am interested in seeing CLOS over on the Mac under (formerly) Allegro Common Lisp. I am under the impression that CLOS itself is freely distributed (various implementations cost $, but CLOS itself, like TeX, is free). Has anyone had any luck porting CLOS to the Mac and possibly expanding the class database to include ToolBox elements (windows, menus, etc)? Thanks -- Jeffrey A. Hallett, PET Software Engineering GE Medical Systems, W641, PO Box 414, Milwaukee, WI 53201 (414) 548-5163 : EMAIL - hallett@gemed.ge.com "Your logic was impeccable Captain. We are in grave danger."
schwamb@ics.uci.edu (Karl Schwamb) (10/25/89)
hallett@positron.uucp (Jeff Hallett x5163 ) writes: >I am interested in seeing CLOS over on the Mac under (formerly) >Allegro Common Lisp. I am under the impression that CLOS itself is >freely distributed (various implementations cost $, but CLOS itself, >like TeX, is free). >Has anyone had any luck porting CLOS to the Mac and possibly expanding >the class database to include ToolBox elements (windows, menus, etc)? Expertelligence has a version of Lisp called Procyon Common Lisp which in addition to being a full CL implementation includes CLOS as well as something they call Common Graphics. They've done a pretty good job of writing Lisp functions which shield you from the toolbox (I think much better than the current version of Allegro). These graphic functions are also implemented in CLOS and, hence, easily extended. If that still doesn't suit you, they have a foreign function interface to C, Pascal, etc. I'm not connected with Expertelligence in any way, just a satisfied customer (well not completely, but then I never am). Karl B. Schwamb schwamb@ics.uci.edu Information and Computer Science University of California, Irvine 92715
barmar@kulla (Barry Margolin) (10/25/89)
In article <1292@mrsvr.UUCP> hallett@gemed.ge.com (Jeffrey A. Hallett (414) 548-5163) writes: >I am interested in seeing CLOS over on the Mac under (formerly) >Allegro Common Lisp. I am under the impression that CLOS itself is >freely distributed (various implementations cost $, but CLOS itself, >like TeX, is free). There's no such thing as "CLOS itself". CLOS is a specification, not a program. As far as I've heard, there are no portable implementations of CLOS, and hence no free ones. You may be thinking of PCL (Portable Common LOOPS), which is close to CLOS but has some minor differences (I don't know the extent of the differences). Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar