# [SERVER] chparent()

Roger Crew (rfc@microsoft.com)
Wed, 20 Mar 1996 19:33:35 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    > 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.
    >