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 ][ [EMAIL PROTECTED] [EMAIL PROTECTED]
[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 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
