octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Graphics properties as objects


From: Shai Ayal
Subject: Re: Graphics properties as objects
Date: Sat, 5 Jan 2008 19:03:17 +0200

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
Shai


reply via email to

[Prev in Thread] Current Thread [Next in Thread]