Re: Graphics properties as objects

[John W. Eaton]

On  4-Jan-2008, Michael Goffioul wrote:

| On 1/3/08, Shai Ayal <address@hidden> wrote:
| > Michael, I can share the work. I am not confident enough I understand
| > you skeleton, but if you post a giude like I did once: "HOWTO add a
| > new property", I will try and make an awk script to automatically
| > generate as much of it as possible.
| 
| Hi,
| 
| While trying to implement my ideas in current graphics code, it appeared
| that using an interface class "property" (mainly there for reference counting)
| was not very handy: props are stored as "property" fields and you somehow
| loose the typing of the property (you can get it back with methods like
| as_xxx_property(void), but if you return a const-reference, you can't do
| whatever you want with the property).
| 
| Another possibility is to deal with pointers:
| 1) get rid of the "property" class and store props as pointers to typed
| property classes:
| 
|     string_property *string;
| 
| 2) implement accessors like:
| 
|     string_property* get_string (void) const { return string; }
|     void set_string (const octave_value& v)
|       { string->set (v); }
| 
| 3) register all properties in a map in base_properties class:
| 
|     std::map<caseless_str, base_property*> all_props;
| 
| 4) property objects are created in the nested "properties"
| classes ctor
| 
| 5) property objects are deleted in ~base_property() by
| iterating over all_props
| 
| I know this scheme does not fit well in the rest of octave code,
| so would this still be acceptable? Any other better idea?

I would really prefer to have the properties be objects instead of
pointers to objects.

What do you really need the map for?

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.

jwe