ZetaBase and immutable objects

[Henry G. Baker]

> If I may be forgiven going on a little more about ZetaBase --
> 
> Henry's argument about immutable, freely copyable objects being cheaper than
> mutable ones applies very directly to ZetaBase.  It doesn't currently have
> support for them, but I don't think it would be hard to add.  Such objects
> would be accessed directly rather than via a handle, giving a performance
> improvement in both space and time.  (Since they're immutable you don't have
> to worry about forwarding, and since they're freely copyable they'll never be
> the target of a cross-segment pointer -- we just copy them into the referring
> segment.)
> 
> -- Scott

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!).  Thus, you
can hack them to your heart's content, until you are happy with them,
and the 'publish' them as shared objects capable of being locked &
unlocked.  Alternatively, you may 'publish' them as immutable objects
which can be referenced and/or copied at will, but don't require
locking.  Neither transition will cause any complaints, since until
the reference is published, no one else can see it.  This is why
linear/unique objects are ideal for 'infant' objects that have just
been born, but haven't yet been initialized, and are therefore
incapable of standing on their own, or being 'seen' in public.

-- 
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html