Hi Sukender and fellow interested parties,
I've finally had a chance to review your meta-data doc (version 4) to see
what you all have been designing, and how we might be able to use it in our
project.
Overall, I must say the design looks good. I really appreciate the effort
you have put into it.
I do have a few design points you may (not) find interesting, so feel free
to accept/modify/comment/ignore as you see fit (as long as you take credit
for any mods/comments that you make ;-) ). If you think I've misunderstood
something, feel free to give me pointers where I may have gone off track; I
only hope I am not stating the obvious, thereby wasting people's time.
1) By deprecating user data and description lists, and integrating them into
the proposed meta-data system until those interfaces are removed, you have
some major side effects:
a) With the current proposal, replacing a meta-data container destroys
any legacy user data or descriptions that may already be present. If this
is a desirable side effect, so be it, but users should be explicitly made
aware of this side effect.
b) User data and description lists will not be a viable work around
(because they will are deprecated) for users who cannot, or will not,
convert to the new meta-data system and also do not wish to replace any
existing meta-data on a node. They will be forced to use some other means
(probably external) to store their data. Again, if this is a desirable side
effect, so be it.
c) For data base accessors, user data and/or description lists may (not)
be totally inappropriate when choosing the "proxy container" route; a
meta-data value that holds a "proxy container" may be preferred. I have
little to know experience with data bases, so others will have more insight
into this sort of thing, but I thought it worth mentioning.
2) I think you might be missing an interface layer that is necessary for the
type system to work for user defined containers that have "proxy" values,
but do not want to pay the default cost of storing a T value:
[code]
// slight mod from current design
class ValueBase : public Referenced
{
protected:
// do we not need a virtual destructor here, since containers will
// hold ref_ptr to this?
virtual ~ValueBase() {}
};
// type specific interface for getting type specific values into/out of
// containers, without revealing how the value itself is stored here
template<typename T> ValueT : public ValueBase
{
public:
// interface layer needs to able to virtually assign values; copy
// constructors need more detail, so we must go to the most derived
// type for that, and we should be using clone for that anyway
ValueT& operator=(const ValueT& val)
{ xassign(val.value()); return *this; }
ValueT& operator=(const T& val) { xassign(val); return *this; }
virtual T & value() = 0;
virtual const T & value() const = 0;
// const so we can use it anywhere excpet for assignment to this
// value
operator T() const { return value (); }
protected:
// derived types tend to need explicitly defined destructors
virtual ~ValueT() {}
private:
// yes, this is virtual and private, but client code should not be
// calling this unless we provided "set" methods other than straight
// assignment; the pattern is unusual, but it works
virtual void xassign(const T& val) = 0;
};
// renamed from "Value<T>" with slight mods
template<class T> class BasicValue : public ValueT<T>
{
public:
//virtual const char * className() const;
/** Constructor*/
BasicValue() {}
/** Contructor from T.*/
BasicValue(const T& val) { _value = val; }
/** Copy constructor*/
BasicValue(const BasicValue<T>& val) { _value = val._value; }
BasicValue& operator=(const T& val) { _value = val; return *this; }
BasicValue& operator=(const BasicValue& val) { _value = val._value;
return *this; }
T & value() { return _value; }
const T & value() const { return _value; }
/* Implicit conversion */
// see ValueT, above
//operator T() { return _value; }
protected:
/** the stored value*/
T _value;
// derived types tend to need explicitly defined destructors
virtual ~BasicValue() {}
/** overloaded == operators, we have to be extra careful because T type
doesn't necessarily have ==
* overloaded.*/
friend inline bool operator==(const BasicValue<T>& left,const
BasicValue<T>& right){ return left._value==right._value; }
friend inline bool operator==(const T& left,const BasicValue<T>& right){
return left==right._value; }
friend inline bool operator==(const BasicValue<T>& left,const T& right){
return left._value==right; }
private:
// virtual assignment for use with the interface layer, ValueT<T>
virtual void xassign(const T& val) { _value = T; }
};
[/code]
By "forcing" users to derive from the interface template, ValueT<T>, you can
guarantee a common type safe interface for casting inside your generic
meta-data containers, without the expense of storing T objects locally.
Your existing class, Value<T> (I renamed it BasicValue<T>) will still work
for initialization with plain old data types and compatible types, but you
do not have to pay for the storage of a potentially useless T object for
more exotic types (data base accessors, etc).
Thanks, again, and I look forward to seeing the final product.
D.J.
On Thu, Apr 28, 2011 at 3:26 AM, Torben Dannhauer <tor...@dannhauer.info>wrote:
> Hi all,
>
> this meta system looks very interesting. I started to implement such a
> system for osgVisual for data management, but it seems that your approach is
> much more sophisticated and finally allows me to plug in my use cases quite
> easy.
> I'm happy that such a framework is developed for OSG. I have cross-read the
> V4 document, but unfortunately I'm currently too much occupied by my
> doctoral thesis to add usefull ideas/components. I'll try to stay up to date
> and maybe can add some comments.
>
> Thanks for your effort, it is great work!
>
> Best regards from Salzburg,
> Torben
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=38841#38841
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
