Chris 'Xenon' Hanson wrote on Tuesday, December 01, 2009 11:06 AM:
> I'm sort of thinking out loud, on (e-)paper here, so feel free to
shoot
> holes in this design:
>
> We design a class called something like CompositeUserData (I dislike
this
> name, and prefer something like UserPropertiesCollection). It is
allocated
> only when requested by one of the UserData/Description/Property APIs.
>
> In it is simply a container (STL map?) of some new class
UserProperty.
> UserProperty could either be an abstract base class with a derived
> implementation for each property type (UserData pointer, Description
string,
> float, etc). Or, it could be a concrete implementation itself of a
single
> class with a member or members that can store any of the possible data
types
> (I think Visual Basic had something called a Variant
> http://en.wikipedia.org/wiki/Variant_type ).
>
> I don't have any preference either way, so perhaps others who have a
dog in
> this race might comment on their feelings for the architecture.
>
> A new API can be added like
>
> setUserProperty("keyname", SOME_TYPE, value);
> and
> value = getUserProperty("keyname", SOME_TYPE);
>
> Not sure if SOME_TYPE is a string or an enum.
>
> We can prevent key name collisions between types, and avoid
considering the
> whole issue of using getUserProperty with the wrong TYPE by
name-manging the
> type into the actual keyname used to store the property. So you could
set a
> STRING of keyname "foo" and a FLOAT of keyname "foo" and they would
co-exist
> because they're actually stored as fooSTRING and fooFLOAT.
>
> In the same way, we can implement the existing UserData and
Description
> APIs with specialized types like "DESC" and "UDATA", so that they
won't
> collide with the generalized API.
>
> The existing Description API seems to respect the order of the
Descriptions
> and existing code might rely on that, so they'd probably be stored
with key
> names like DESC00001, DESC00002, etc to preserve the order.
This seems overly complicated to me; couldn't we just rely on users
knowing the type they want for a given key, like we rely on them knowing
what subclass of UserData they want now? That way, UserPropertyContainer
is simply an std::map<string,ref_ptr<Referenced> >. The UserData API
would store its Referenced pointer, and the Description API could store
a vector of strings:
Pseudocode:
void setUserProperty(std::string& key, Referenced* property) {
if ( !_userProperties ) { _userProperties = new
UserPropertyContainer(); }
(*_userProperties)[key] = property;
}
Referenced* getUserProperty(std::string& key) { return _userProperties ?
(*_userProperties)[key] : NULL; }
void setUserData(Referenced* ref) { setUserProperty("osg.userdata",ref);
}
Referenced* getUserData() { return getUserProperty("osg.userdata"); }
class DescriptionList : public std::vector<std::string>, public
Referenced {};
void getDescription(int i) {
DescriptionList* descList = getUserProperty("osg.descriptions");
if ( !descList ) { descList = new DescriptionList();
setUserProperty("osg.descriptions",descList); }
return (*descList)[i];
}
etc. etc. etc.
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
