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