[vos-d] s5 properties again

[Peter Amstutz]

Some ideas for a new design for properties.

Replace the vobject "child list" with a "property map".  A property is a 
slot that holds some value, which can be a basic type (int, string), a 
compound type (struct, array or map) or a reference to another vobject.  
Reflection permits iterating over all entries in the property map.

Unlike links in the child list, the order of properties is not 
significant, and two properties of the same name are not allowed.  Where 
order is important, data can be stored in an array property.

Paths are still available.  For example:

/vos/Namespaces/core/Types/String

Where
"vos" is a vobject
"Namespaces" is a map of names to vobject references
"core" is a reference to a particular vobject
"Classes" is another map, part of "core"
"String" is a reference to another vobject

Another example:

/scene/objects/_2/position/x

Where
"scene" is a vobject
"objects" is a list of vobject references
"_2" is the reference at index 2 in the list
"position" is an xyz vector struct
"x" is the x member of the struct

At any point you can get a "directory" of properties underneath some 
path, along with a reference to the VOS type.

/scene/objects/_2/position/*
 would yield
"x" (/vos/Namespaces/core/Types/Float)
"y" (/vos/Namespaces/core/Types/Float)
"z" (/vos/Namespaces/core/Types/Float)

/scene/objects/_2/*
 would yield 
"position"    (/vos/Namespaces/a3dl/Vector3)
"orientation" (/vos/Namespaces/a3dl/Vector4)
"color"       (/vos/Namespaces/a3dl/Color)

And so forth.

Properties would be referenced using a vobject id + path.  Properties 
would be manipulated (get/set methods) by sending messages to the parent 
vobject and including the path to the property of interest.

Vobjects subscribe to property changes by providing the path referring 
to the property of interest.

Reflection would hold additional metadata describing properties, such as 
which properties should be automatically stored for serialization and 
persistance.

Vobject references would support both "hard" links (link to a specific 
vobject id) and "soft" links (where there is a relative path that must 
be resolved to determine the actual vobject).

In addition to "embedded" properties (those which are part of the state, 
which are always there) the user would be able to attach their own 
"override" properties.

An override property would be either an entirely new property, or 
replace an existing embedded property.  Matching an override would be 
path based, for example:

addOverride("/object/position/x", 22)

Would change the "x" component of the position to 22.  Any read or write 
to "x" or "position" would use the override, rather than the underlying 
value.  Removing the override would restore the old value.

The override could provide a slot to store the value, it could tie the 
get/set operations to some other property of the same type (referenced 
as a vobject + path), or it could tie the get/set operations to some 
other methods a vobject.


Advantages of this approach:
 - This makes the vobject model is much closer to the most common idea 
of objects as "methods" + "properties".

 - A purely dynamic implementation is easy using maps and lists.

 - A static implementation (where the underlying properties are 
zero-memory-overhead) is straightforward using code generation.

 - Serialization, peristance, synchronization and replication are easier 
since purely declarative data (state) is distinct from the imperative 
methods that manipulate it.


Disadvantages:
 - It "isn't VOS" since it discards the last trappings of the s4 vobject 
model

 - It's going back to the drawing board (again) (not completely, but it 
does mean some work redesigning the VOS APIs, the XOD format, changing 
the code generator, etc)

Thoughts?

-- 
[ Peter Amstutz ][ tetron at interreality.org ][peter.amstutz at tseboston.com]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20080501/12c4401f/attachment.pgp