RE: [SERVER] chparent()

• Date: Wed, 20 Mar 1996 19:33:35 PST
• From:
  Roger Crew <rfc@microsoft.com>
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset="us-ascii"

> I know that it is so with create(), but when a chparent() is done,
> does the :initialize() verb on the changed object get called?
> If not, why?  And, if there is no reason why this would be a
> bad thing, I'd like to add it to the wish-list for future servers...

There was a fair amount of discussion about this a few years back (check
the MOO-Cows archives from 9/92).  Various answers in no particular
order:

As of 1.8.0p2, you can do $server_options.protect_chparent = 1 and add a
$bf_chparent() verb to make chparent() do just about anything you want;
no server hacking needed.

Neither :initialize() nor :recycle() gets called on chparent().  That
this doesn't happen is generally regarded as a bad thing, but the amount
of hair involved in implementing something sufficiently good to be
usable has (evidently) prevented anything from happening on this front.

If chparent() were changed to call :initialize()/:recycle(), it still
would not guarantee that the :initialize (:recycle) verb gets called for
every descendant of a given object, since any descendant is free to
define its own version that doesn't pass().  Arguably, there should be
something to force *each* :initialize verb in the sequence of ancestors
should be called, but then you get the rather interesting question of
what should happen if one of them raises an error.

And then there's the Battling Hierarchies of Voodoo Dolls Scenario, in
which :initialize()/:recycle() verbs themselves call chparent(), whether
it be direct chparent(this,...) calls or other more convolutedly
self-referential such calls.

I did once have a proposal (see 9/92) about the Right Thing to do with
:initialize/:recycle.
Summary:  Life gets easier if you view create()/recycle()/chparent() as
a sequences of atomic
   specialize() -- chparent to sibling, call :initialize
   generalize() -- call :finalize, chparent to grandparent
operations, accepting the possibility of create(), recycle(), or
chparent() bombing out in the middle if some :initialize/:finalize
raises an exception.  This may even be more palatable now that one can
finally do exception handling.  
The only hazy spot is whether to allow (or how to prevent) the
parent-hierarchy version of trapping exitfuncs.  As it happens, I
currently think that a trapping :finalize would be useful, because then
you could e.g., supposing you want every object owner to be a descendant
of $generic_owner, really *guarantee* that no owner gets recycled until
everything it owns has either been recycled or chowned to someone else.
This should likewise be implementable in 1.8.0 without any server hacks.
>

• Prev: Re: [SERVER] chparent()
• Next: RE: [SERVER] chparent()
• Index: MOO-cows
• Thread: MOO-cows