Re: Graphics properties as objects

[Shai Ayal]

On Jan 5, 2008 9:06 PM, John W. Eaton <address@hidden> wrote:
> On  5-Jan-2008, Shai Ayal wrote:
>
>
> | On Jan 5, 2008 6:40 PM, John W. Eaton <address@hidden> wrote:
> | > On  4-Jan-2008, Michael Goffioul wrote:
> | >
> | >
> | > | On 1/4/08, John W. Eaton <address@hidden> wrote:
> | > | > I would really prefer to have the properties be objects instead of
> | > | > pointers to objects.
> | > | >
> | > | > What do you really need the map for?
> | > |
> | > | I think it significantly simplify any code that access properties
> | > | by name, because it provides a unified access.
> | > |
> | > | > Even if they are not stored in a map, all property types can still be
> | > | > derived from a base class that stores things like the hidden flag.
> | > |
> | > | Indeed, that's what I have for the moment. Actually, I just thought
> | > | about something else. Keep the property field as typed classes
> | > | in the nested "properties" classes (as it is now); keep the interface
> | > | "property" class (as I proposed) as unified access and for reference
> | > | count; store all properties in a std::map<caseless_str,property>,
> | > | but for fixed properties, artificially increment the internal count by
> | > | one to take into account the field use for direct access. That is
> | > | something like this:
> | > |
> | > |     string_property string;
> | > |
> | > |     const string_property& get_string (void) const { return string; }
> | > |
> | > |     void set_string (const octave_value& v) { string = v; }
> | > |
> | > | and to store the property in the global map, do something like
> | > | (conceptually):
> | > |
> | > |     property p (&string);
> | > |     p.increment_count_by_one ();
> | > |     xproperties.add (p);
> | > |
> | > | Would this be better?
> | >
> | > Is it even necessary to have the base class do reference counting
> | > here?
> | >
> | > Since the properties are tied to the graphics objects that contain
> | > them, shouldn't we only expect them to exist as long as the graphics
> | > object exists?
> | >
> | > If individual properties do need to exist longer than the graphics
> | > objects that contain them, then wouldn't it be sufficient to simply
> | > have a copy of the property?  Aren't most (all) of the property
> | > classes composed of objects that are already reference counted?  So
> | > copying them should be relatively cheap and since they are passed
> | > around by value, they should not be deleted unnecessarily?
> | >
> | > Why should get_string return a reference instead of a value?
> |
> | Also, there is probably a typo there since I would expect it to return
> | an octave_value
>
> I think we want the get_X functions (like get_string above) to return
> specific property types.  It's the generic get function (the one that
> takes a property name as a string) that should return an octave_value
> (or an object of the base property class, which can be converted to an
> octave_value).
of course. sorry about that