Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object
Subject: Re: Availability of class extension (was: value semantic versus...)
Message-ID: <1991May30.183150.17303@odi.com>
Date: 30 May 91 18:31:50 GMT
References: <1991May14.093053.3017@jyu.fi> <3683@sequent.cs.qmw.ac.uk> <4851@osc.COM> <1991May22.053938.20827@jyu.fi> <4863@osc.COM> <1991May28.232832.28284@cs.ucla.edu> <1991May29.134314.6850@odi.com> <1991May30.003525.21161@cs.ucla.edu>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 42
In-Reply-To: rowley@bath.cs.ucla.edu's message of 30 May 91 00:35:25 GMT

In article <1991May30.003525.21161@cs.ucla.edu> rowley@bath.cs.ucla.edu (Michael T Rowley) writes:

   the important words are "within this set of employees".  The
   interesting set of employees may only be reachable through a multi-step
   navigation through the network.  In which case, the user would be
   reduced to writing imperative programs to retrieve his data.  I think
   the user community will balk at this.

(1) May or may not.  If you are using a non-enforced-extent OODB, you
are perfectly free to maintain extents anyway.  Or there might be
several sets of employees, all of which are stored in global
variables.  A non-enforced-extent OODB gives you the freedom to build
up complex structures, but you don't have to use it if you don't want to.

(2) Which user community?  Different user communities have different
ideas about how they want to organize data.  Consider the existing
community of ECAD software developers.  They write in programming
languages such as Pascal or C++, and they generally don't store their
transistors and so on in database systems.  I think you'll find that
they don't all maintain a concept of "the set of all resistors" and so
on for every data type in the entire system.  Just because they want
to switch to using an OODB does not necessarily mean that they want to
change their whole idea of how to organize their data structures.  In
fact, it might even be a goal to *not* be forced into changing all of
the data structures.  Perhaps you would argue that they are all wrong;
that they really ought to change their data structures; that they have
been suffering for years with an inferior notion, and they are simply
unware of their own pain.  I don't know how many of them you'd
persuade.  A key question is why databases should be so different from
programming languages in this regard.  Surely questions of
persistence, concurrency control, and recovery have nothing to do with
it.  Why doesn't Pascal have a way to say "iterate over all the records
of type foo?", and why don't people think that this lack makes Pascal
unacceptable?

   Hence, I think all objects in an OODB should be easily reachable from
   globally known objects.  The most obvious candidates for such objects
   in an OODB would be collections representing the extents of the
   classes.

I certainly think any OODB should allow you to do this.  The only
question is whether it should force you to do this.