ZetaBase and immutable objects

[Scott L. Burson]

   From: hbaker@netcom.com (Henry G. Baker)
   Date: Fri, 23 May 1997 14:58:24 -0700 (PDT)

   > Henry's argument about immutable, freely copyable objects being cheaper than
   > mutable ones applies very directly to ZetaBase.

   While you're at it, I think that you may find linear/unique objects
   just as useful, since linear/unique objects are mutable, but don't
   require locking (remember, you have the only reference!).

Heh.  You point up a bug in my little plan to add immutable objects to
ZetaBase.  Namely: there is a period of time between when an immutable object
comes into existence and when it becomes freely copyable.  One solution is
always to create and initialize them uninterruptibly, and that might be the
best thing, but it would be unfortunate to have to do that when the object is
large (a color image, say).  The solution you are proposing, as I understand
it, is to arrange to know at compile time that the only possible reference to
the object during the time it's being initialized is the one on the stack of
the thread that's initializing it, so the GC can still move it as long as it
updates that reference (and encountering that reference is the only reason the
GC *would* move it).

Hmm.  We already know that in an object-oriented language, a constructor need
not lock the object it's constructing.  One can translate your proposal into
the rule that a constructor for an immutable object not be able to reference
`this' (aka `self').  I find this a more elegant formulation.

-- Scott