MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Changing parents & dynamic properties

At 08:43 AM 1/24/96 PST, Stephan Szabo <acroyear@cyberwar.com> wrote:
>	If the property on the parent has the 'c'lear permission set, its 
>behavior is different.
>	The parent gets a value for the property, and the children only 
>get placeholders which say, if you want to read this property, go to my 
>parent and read it from him.
>        So, when you read from the child, you are actually getting the 
>value as set on the parent.  When you write to the child, you are 
>replacing the placeholder with the value you wrote in and the child will 
>no longer echo changes of the parent's value.

Er, what?  I beleive the vernacular for the 'c' flag is "*C*hange ownership"

>From the Programmer's Manual:
------
   The permissions on properties are drawn from this set: `r' (read), `w'
(write), and `c' (change ownership in descendants).  Read permission lets
non-owners get the value of the property and, of course, write permission lets
them set that value.  The `c' permission bit is a little more complicated.

   Recall that every object has all of the properties that its parent does and
perhaps some more.  Ordinarily, when a child object inherits a property from
its parent, the owner of the child becomes the owner of that property.  This
is because the `c' permission bit is "on" by default.  If the `c' bit is not
on, then the inherited property has the same owner in the child as it does in
the parent.

   As an example of where this can be useful, the LambdaCore database ensures
that every player has a `password' property containing the encrypted version
of the player's connection password.  For security reasons, we don't want
other players to be able to see even the encrypted version of the password, so
we turn off the `r' permission bit.  To ensure that the password is only set
in a consistent way (i.e., to the encrypted version of a player's password),
we don't want to let anyone but a wizard change the property.  Thus, in the
parent object for all players, we made a wizard the owner of the password
property and set the permissions to the empty string, `""'.  That is,
non-owners cannot read or write the property and, because the `c' bit is not
set, the wizard who owns the property on the parent class also owns it on all
of the descendants of that class.

   Another, perhaps more down-to-earth example arose when a character named
Ford started building objects he called "radios" and another character, yduJ,
wanted to own one.  Ford kindly made the generic radio object publicly
readable, allowing yduJ to create a child object of it, her own radio.  Radios
had a property called `channel' that identified something corresponding to the
frequency to which the radio was tuned.  Ford had written nice programs on
radios (verbs, discussed below) for turning the channel selector on the front

of the radio, which would make a corresponding change in the value of the
`channel' property.  However, whenever anyone tried to turn the channel
selector on yduJ's radio, they got a permissions error.  The problem concerned
the ownership of the `channel' property.

   As I explain later, programs run with the permissions of their author.  So,
in this case, Ford's nice verb for setting the channel ran with his
permissions.  But, since the `channel' property in the generic radio had the
`c' permission bit set, the `channel' property on yduJ's radio was owned by
her.  Ford didn't have permission to change it!  The fix was simple.  Ford
changed the permissions on the `channel' property of the generic radio to be
just `r', without the `c' bit, and yduJ made a new radio.  This time, when
yduJ's radio inherited the `channel' property, yduJ did not inherit ownership
of it; Ford remained the owner.  Now the radio worked properly, because Ford's
verb had permission to change the channel.
----
The C flag has nothing to do with a property's clear-ness.
Home | Subject Index | Thread Index