[comp.object] Static v. Dynamic Class Structure

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.

   -andrew

hallett@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