Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!pacbell!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.object
Subject: Re: value semantic versus reference semantic
Summary: A class is abstract.
Keywords: distribution, values, object identity, immutability
Message-ID: <4863@osc.COM>
Date: 25 May 91 00:58:05 GMT
References: <1991May14.093053.3017@jyu.fi> <3683@sequent.cs.qmw.ac.uk> <4851@osc.COM> <1991May22.053938.20827@jyu.fi>
Reply-To: jgk@osc.COM (Joe Keane)
Organization: Versant Object Technology, Menlo Park, CA
Lines: 67

In article <4851@osc.COM> some radical guy writes:
>The whole idea of asking for all instances of a class is wrong.  Such a
>facility should not be provided.

In article <1991May22.053938.20827@jyu.fi> sakkinen@jytko.jyu.fi (Markku
Sakkinen) writes:
>This is somewhat too strong an opinion.  Funny that it comes from a person
>working for an OODB company (right?) -- especially many object database
>people often think that the "class as collection" aspect is also necessary,
>and it is analogous to most other database models.

I'd say that's what containers are for.  Suppose you want to be be able to
find something like resistors.  If you're smart you'd put them together in a
box, and maybe sort them by value.  You don't find all the resistors in the
universe, and then pick out those that have the right value and belong to you.

If you want to find all the instances of a given class in some container,
that's fine with me.  We even let you find all the instances of a given class
in a given database.  I don't think this is a great idea, but you can do it.

But how about `find all instances of a given class'?  What does it mean?  Find
all instances in memory?  In general only some of the objects you're working
with are actually in main memory at a given time, and the whole point of an
ODBMS is to hide whether objects are `in' or `out'.  Find all instances in all
databases you're connected to?  Again, which databases you're connected to
should not be such an important part of your state.  Find all instances in all
databases in existence?  This makes sense, but it has some obvious practical
problems.

>Example advantage:
> - class (or schema) evolution:  one often has to convert all existing
>   instances to fit the new class definition.

No, that's the old way to do it.  Relational database users tell horror
stories about how it took a day to add a column to a large table.  Of course,
during this time, the database is unusable.  The same criticism applies at
least as much to objects.  Without getting to much into details, i'll just
note that our product has lazy schema evolution.  You can make a new version
of class, but the old instances aren't converted to the new schema until
they're used.

>Example disadvantage:
> - clashes with access rights in a database:  e.g. what is a user entitled
>   to know about possible instances not accessible to him/her in a class?

Right.

On another topic, i wrote:
>But the same argument applies to mutable objects too.  If two mutable objects
>happen to have the same value, they can still share space for it.  Then if one
>of the objects is changed, you have to copy its value before making the
>change.  This is analagous to `copy on write' for pages in a virtual memory

Markku writes:
>Not quite so, although the main principle is good.  The programmer must
>define a "front end" class for the objects that clients are allowed
>to see, and a "back end" class for hidden objects to which the visible
>objects contain references.  The back end objects then contain the
>actual data and reference counts, and the above tactic can be applied
>to them.

I think we're saying the same thing:
`front end' = reference = mutable object
`back end' = value = immuable object
--
Joe Keane, amateur mathematician
jgk@osc.com (...!uunet!stratus!osc!jgk)