<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.51
from ProgrammersManual.texinfo on 4 March 1997 -->
<TITLE>LambdaMOO Programmer's Manual - Properties</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="ProgrammersManual_1.html">first</A>, <A HREF="ProgrammersManual_5.html">previous</A>, <A HREF="ProgrammersManual_7.html">next</A>, <A HREF="ProgrammersManual_77.html">last</A> section, <A HREF="ProgrammersManual_toc.html">table of contents</A>.
<P><HR><P>
<H3><A NAME="SEC6" HREF="ProgrammersManual_toc.html#TOC6">Properties on Objects</A></H3>
<P>
A <STRONG>property</STRONG> is a named "slot" in an object that can hold an arbitrary
MOO value. Every object has eight built-in properties whose values are
constrained to be of particular types. In addition, an object can have any
number of other properties, none of which have type constraints. The built-in
properties are as follows:
</P>
<PRE>
name a string, the usual name for this object
owner an object, the player who controls access to it
location an object, where the object is in virtual reality
contents a list of objects, the inverse of <SAMP>`location'</SAMP>
programmer a bit, does the object have programmer rights?
wizard a bit, does the object have wizard rights?
r a bit, is the object publicly readable?
w a bit, is the object publicly writable?
f a bit, is the object fertile?
</PRE>
<P>
The <SAMP>`name'</SAMP> property is used to identify the object in various printed
messages. It can only be set by a wizard or by the owner of the object. For
player objects, the <SAMP>`name'</SAMP> property can only be set by a wizard; this
allows the wizards, for example, to check that no two players have the same
name.
</P>
<P>
The <SAMP>`owner'</SAMP> identifies the object that has owner rights to this object,
allowing them, for example, to change the <SAMP>`name'</SAMP> property. Only a wizard
can change the value of this property.
</P>
<P>
The <SAMP>`location'</SAMP> and <SAMP>`contents'</SAMP> properties describe a hierarchy of
object containment in the virtual reality. Most objects are located
"inside" some other object and that other object is the value of the
<SAMP>`location'</SAMP> property. The <SAMP>`contents'</SAMP> property is a list of those
objects for which this object is their location. In order to maintain the
consistency of these properties, only the <CODE>move()</CODE> function is able to
change them.
</P>
<P>
The <SAMP>`wizard'</SAMP> and <SAMP>`programmer'</SAMP> bits are only applicable to
characters, objects representing players. They control permission to use
certain facilities in the server. They may only be set by a wizard.
</P>
<P>
The <SAMP>`r'</SAMP> bit controls whether or not players other than the owner of this
object can obtain a list of the properties or verbs in the object.
Symmetrically, the <SAMP>`w'</SAMP> bit controls whether or not non-owners can add or
delete properties and/or verbs on this object. The <SAMP>`r'</SAMP> and <SAMP>`w'</SAMP> bits
can only be set by a wizard or by the owner of the object.
</P>
<P>
The <SAMP>`f'</SAMP> bit specifies whether or not this object is <STRONG>fertile</STRONG>, whether
or not players other than the owner of this object can create new objects with
this one as the parent. It also controls whether or not non-owners can use the
<CODE>chparent()</CODE> built-in function to make this object the parent of an
existing object. The <SAMP>`f'</SAMP> bit can only be set by a wizard or by the owner
of the object.
</P>
<P>
All of the built-in properties on any object can, by default, be read by any
player. It is possible, however, to override this behavior from within the
database, making any of these properties readable only by wizards. See the
chapter on server assumptions about the database for details.
</P>
<P>
As mentioned above, it is possible, and very useful, for objects to have other
properties aside from the built-in ones. These can come from two sources.
</P>
<P>
First, an object has a property corresponding to every property in its parent
object. To use the jargon of object-oriented programming, this is a kind of
<STRONG>inheritance</STRONG>. If some object has a property named <SAMP>`foo'</SAMP>, then so
will all of its children and thus its children's children, and so on.
</P>
<P>
Second, an object may have a new property defined only on itself and its
descendants. For example, an object representing a rock might have properties
indicating its weight, chemical composition, and/or pointiness, depending upon
the uses to which the rock was to be put in the virtual reality.
</P>
<P>
Every defined property (as opposed to those that are built-in) has an owner
and a set of permissions for non-owners. The owner of the property can get
and set the property's value and can change the non-owner permissions. Only a
wizard can change the owner of a property.
</P>
<P>
The initial owner of a property is the player who added it; this is usually,
but not always, the player who owns the object to which the property was
added. This is because properties can only be added by the object owner or a
wizard, unless the object is publicly writable (i.e., its <SAMP>`w'</SAMP> property is
1), which is rare. Thus, the owner of an object may not necessarily be the
owner of every (or even any) property on that object.
</P>
<P>
The permissions on properties are drawn from this set: <SAMP>`r'</SAMP> (read),
<SAMP>`w'</SAMP> (write), and <SAMP>`c'</SAMP> (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 <SAMP>`c'</SAMP> permission bit is a little
more complicated.
</P>
<P>
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 <SAMP>`c'</SAMP> permission bit is "on" by default. If the <SAMP>`c'</SAMP>
bit is not on, then the inherited property has the same owner in the child as
it does in the parent.
</P>
<P>
As an example of where this can be useful, the LambdaCore database ensures
that every player has a <SAMP>`password'</SAMP> 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 <SAMP>`r'</SAMP> 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,
<CODE>""</CODE>. That is, non-owners cannot read or write the property and, because
the <SAMP>`c'</SAMP> 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.
</P>
<P>
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 fertile, allowing
yduJ to create a child object of it, her own radio. Radios had a property
called <SAMP>`channel'</SAMP> 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 <SAMP>`channel'</SAMP>
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 <SAMP>`channel'</SAMP> property.
</P>
<P>
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 <SAMP>`channel'</SAMP> property in the generic radio had the <SAMP>`c'</SAMP>
permission bit set, the <SAMP>`channel'</SAMP> 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 <SAMP>`channel'</SAMP> property of the generic radio to
be just <SAMP>`r'</SAMP>, without the <SAMP>`c'</SAMP> bit, and yduJ made a new radio. This
time, when yduJ's radio inherited the <SAMP>`channel'</SAMP> 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.
</P>
<P><HR><P>
Go to the <A HREF="ProgrammersManual_1.html">first</A>, <A HREF="ProgrammersManual_5.html">previous</A>, <A HREF="ProgrammersManual_7.html">next</A>, <A HREF="ProgrammersManual_77.html">last</A> section, <A HREF="ProgrammersManual_toc.html">table of contents</A>.
</BODY>
</HTML>