Set, clear and force in v5

In order to understand the new choices "clear" and "force" in the Object Editor, one has to understand the concept of inherited properties and inherited values. The first section will explain the theory behind the choices, the second section will point out where to find them.

Real life example

Consider these women: Eve, Liv, Vivian, Aischa. Now, Liv is the mother of Vivian, and Vivan is the mother of Aischa. They all are remote descendants of Eve. Let's put it in a tree.

. Eve . . '--- Liv '---- Vivian '----- Aischa

Now, Eve was just Eve. Since she was alone on Earth, she didn't have a last name. She didn't need any. The concept of having a last name was unheard of, and not necessary, thus non-existant. In programmers' terms, if you asked Eve for the value of her property "last name", she would return "oooops, Error, there is no last name: Property Not Found".

Eve.last_name => E_PROPNF

But somewhere along the line, people were fruitful and multiplied, and the need for a last name arose. So our grandma Liv actually got a last name. She married a guy with the last name Anderson, and her name was Liv Anderson ever after. In programmers' terms,

Liv.last_name => "Anderson"

Now, by virtue of being descendants of Live, both Vivian and Aischa inherit the name "Anderson". Of course, Vivian and Aischa didn't deliberately choose that name, it is just passed on. It's the family name. In programmers' terms,

Liv.last_name => "Anderson"
Vivian.last_name => "Anderson"
Aischa.last_name => "Anderson"

What these lines do NOT tell, is that Vivian's last name is not "Anderson" because Vivian chose it, but because Liv chose it. Whatever Liv decides to change her name to, Vivian's name will be. This is inheritance. So if Liv changes her name to Hanson, the family would look like

Liv.last_name => "Hanson"
Vivian.last_name => "Hanson"
Aischa.last_name => "Hanson"

Unless Vivian goes to the Town Registry Hall and says (by marriage or whatever): My name should be Olson from now on. Then we would have a family tree like this:

Liv.last_name => "Hanson"
Vivian.last_name => "Olson"
Aischa.last_name => "Olson"

Note that Aischa still follows her mum Vivian in whatever she does, regardless of what Liv does. In this example, Liv can change her name again to "Harrison", not affecting her daughters' names, since Vivian made clear once and for all that her name and all of her descendants' names will be "Olson".

Liv.last_name => "Harrison"
Vivian.last_name => "Olson"
Aischa.last_name => "Olson"

Aischa is too young to make her own decisions, she will follow whatever her mother descides to do. If Vivian changes her name to "Thompson", Aischa will follow, without giving it a second of consideration. Unless she grows up and decides to go to the Town Registry and put her own last name in the Town records and say, "This is my name wich I will keep".

But how do we find out that a name is deliberately chosen, or just passively passed on and inherited? From the list above, there is no way of finding out whether a value will change when the parent's value change, or whether it will stay put. The value itself doesn't give any clues about this.

The lambdamoo server calls this "clear property" and "set property". Note that CLEAR does NOT mean "empty", "void", "zero", "undefined" or "non-existant". It simply means "transparent".

The status can be checked and set by the builtin functions
is_clear_property(object, name) clear_property(object, name) So in this last example, checking the status of the property values would give this:
is_clear_property(Liv, "last_name") => 0 [not clear, but set] is_clear_property(Vivian, "last_name") => 0 [not clear, but set] is_clear_property(Aischa, "last_name") => 1 [clear, not set]

Note that the property, or its LABEL, exists on all the women Liv, Vivian and Aischa. In the history of objects (parenting tree), it was first introduced with Liv, meaning that Eve didn't have a last name, but the descendants of Liv do.

The icon property

So unless you as a player deliberately set your icon to be anything, you will have an icon that is defined for you and that is SET on the parent object, say, the Generic Player, with the value, say, "player.gif". Whenever a wizard decides to change the Generic Player Icon, to, say, "bettericon.gif", you will have this new icon displayed next to your name. This is because the information on the clear- status on your icon property value says "clear".

There is of course no way to prohibit you from deliberately set YOUR icon value to "player.gif", thus making the value SET and not CLEAR. This is, of course, not needed, but it prevents your icon from being changed when a wizard decides to change it for the whole class of objects descending from the Generic Player.

The Object Editor in v3 and v5

In v3, there was no way to see if a property was clear or set. All there was to see was its value. As to actions, you could just SET the property value to something, and not CLEAR it again. But more than that (and this is important) - if the new value was exactly the old value, the information would NOT be overwritten and SET, but it would be silently left as it was. The picture below shows that there is just one button in v3:

In v5, there is (a) the possibility to SET clear values to the value the parent currently has (this is done with the check box "force value if clear"), and (b) the possibility to CLEAR the value once it's set (see the scond submit- button).

Of course, objects which do not inherit vital properties, like the $network object, do not have these additional boxes; they wouldn't make sense.

The Program Editor in v3 and v5

The Program Editor in v3 didn't tell if the value was clear either, nor where the property comes from (the oldest parent defining the LABEL), or where its value is inherited from (the oldest non-clear parent).

This has changed considerably in v5, where it tells all of the information lacking above. Consider the screenshot below, where it states:

This property is clear. It is inherited from $root_class.icon. Its specific value is inherited from $wiz.icon. Press 'set' to explicitly define the inherited value, or to save changes.

Note that the references are clickable and will lead to the respective pages where the respective objects' values can be set (if you own them).


Here as well, the property can be set or cleared.

Since the inheritance information now plays a much bigger and more visible role, the list of properties displayed in the Program Editor is now separated by objects on which they are defined. In the screenshot below, the properties private to the Wizard #2 are shown as "native", then, all properties defined on the next parent (Generic Wizard) are listed as "inherited", then, the Generic Programmer's properties etc. For convenience, the properties can be sorted a lphabetically or by order of appearance.

(End of file)