Subject: clear properties, possible hazard

From: [email-masked] (Erik Ostrom)
Date: Wed, 9 Sep 1992 15:43:47 -0700

For those who don't read *core-db-issues@LambdaMOO:

Message 679 on *Core-DB-Issues (#8175):
Date:     Mon Sep  7 10:14:14 1992 PDT
From:     JoeFeedback (#2612)
To:       *Core-DB-Issues (#8175)
Subject:  Re: .help_msg

>  The .help_msg shouldn't be a problem with clear properties; it
>  will no longer get copied to children.  The only problem is with
>  existing children of generics with large .help_msg's... And it's
>  easy enough to just @clearp those. :)

Actually, it's so easy, it's ALREADY DONE.  New .help_msg properties will be
set clear on descendants; and someone went through and cleared all properties
that are the same as those on their parents (Is that clear?), or at least all
those that I've looked at.

This is a kind of warning: The behavior of clear properties is not the same as
the prior behavior of properties equal to their parents', because changing a
parent's property will drag all the clear properties along with it.  This may
be a problem if you have a usable object that others' objects are descended
from.  For example, if you have a shoelace with a .tied_property, and people
have made children of it, and your shoelace's .tied and another shoelace's
.tied happened to both be empty when the Great Clearing was done, then tying
your shoelace to someone will *also tie someone else's shoelace*.  For that
matter, new children of your shoelace will be in the same predicament, and if
the .tied property is +c (never mind how unlikely that is), then I suspect
you'll have no way of clearing it except printing instructions to the new
owner, and hoping e's a programmer.
--------------------------

More comment on the situation: yduJ and others seem convinced that
this (dragalong) is the way properties should have worked all along.
I'm pretty convinced that it's a bug.  However, it's possible to
compensate for newly created objects whose properties you don't want
clear.  The programmer must make the important properties !c (which I
think is generally a good idea anyway), and write something like this
(from Sick's message on *core-db-issues):

	this.<prop> = parent(this).<prop>;

in the parent object's :initialize verb.

There are two cases that this doesn't provide for:

	1) A mass clearing of properties, such as the one that was
just done on LambdaMOO.  While such a clearing seems necessary if
clear properties (under the current implementation) are to do any
good, it means that people have to go through their objects and make
sure no properties are clear that shouldn't be.  In a huge
many-programmer database like LambdaMOO, it's impossible to get
everyone to check; in a large multi-programmer db, I'd guess it would
merely be painful.

	2) chparent().  When I suggested (again on *core-db-issues)
that you could take care of everything with a good :initialize verb,
APHiD pointed out that ":initialize() only works some of the time
since it isn't called by @chparent."  chparent() is a major pain
because, unlike create() and recycle(), it doesn't let any of the
objects involved know what's going on.  (Among other things, this is
the only reason the LambdaMOO Helpful Person Badges are all owned by
me--the topic database can't afford to have a badge chparented without
being notified.)

So anyway, if clear properties are going to stay, and maintain their
behavior, we really need for chparent() to call a verb, or, more
likely, two verbs.  Blackbriar created a model of this on ChaosMOO, in
which $object_utils:chparent did, in part:

	... stuff involving chparent(victim, new_parent)...
	new_parent:get_a_kid(victim, old_parent);
	old_parent:lose_a_kid(victim, new_parent);

Another possibility would be:

	victim:will_chparent(new_parent);
	... stuff involving chparent(victim, new_parent)...
	victim:did_chparent(old_parent);

This presumably has roughly the same effect, but it allows
object-specific code to be executed, and it's somewhat simpler.  On
the other hand, both of these schemes can mess up ancestors if a verb
anywhere along the line doesn't pass(@args).

We could discuss specifics some more, but I think chparent()
desperately needs some form of notification.
--------------------------

The other option is changing clear properties.  Clear properties could
go away, which would be sad, because they save space.  Alternatively,
clear properties could not be dragged along with their parents, in
which case we could get rid of the clear_property() and
is_clear_property() primitives, since clarity would be, well,
transparent.  This would still save space; however, it would involve
unclearing a number of properties (and possibly clearing properties
that suddenly become in line with the parent) on every property
assignment.  This might be a drag.  On the other hand, changing
properties on parent objects probably doesn't happen all that often.

I guess there are two points to this message: a caution about the
behavior of clear properties, and a suggestion that _something_ needs
to be changed, whether it be chparent(), clear properties, or
something I haven't thought of.  I'd like to see some sort of
discussion on this, at any rate; the present situation makes me
uncomfortable, but I'm not sure about the proper way to change it.

Erik/JoeFeedback