Re: Graphics properties as objects

[John W. Eaton]

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).

jwe