Hi, all...
I just realized, if you write your proxy correctly, your original class
Value<T> probably works just fine for more exotic types (when T is your
proxy class giving access to the underlying type), without my proposed
interface layer. In fact, for purposes of reference semantics, the original
is probably preferred.
Perhaps I should have read that doc more than three times...
Regardless, I look forward to your comments and the final product.
D.J.
On Fri, Apr 29, 2011 at 11:01 PM, D.J. Caldwell <dlcaldwel...@gmail.com>wrote:
> 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
