Re: Graphics properties as objects

[Michael Goffioul]

On 1/2/08, John W. Eaton <address@hidden> wrote:
> |   string_property& as_string_property (void) const
> |     { return *(reinterpret_cast<string_property*> (rep)); }
>
> Since this is  casting within the inheritence hierarchy, shouldn't
> this use dynamic_cast?

Probably yes.

> Also, should it really return a non-const reference?  Since rep is
> shared, wouldn't that allow someone to modify multiple copies?  Is
> that really what you want here?

A const reference might be OK. I didn't think about this deeply.
For the moment, I cannot figure out a use-case where a non-const
reference might be needed.

> | >>>>> property set in base_properties <<<<<
> |
> | class OCTINTERP_API base_properties
> | {
> | //...
> | public:
> |   void add (base_property *bp)
> |     { all_props[bp->get_name ()] = property (bp); }
>
> Where is this function used?

Nowhere, it's more to make the API complete. And in my first attempt,
I thought about registering properties to the map in the base_property
ctor (kind of automatic registering): but in that case, the base_property
ctor would somehow need an access to the containing "properties"
object, which it does not have (it has access to the graphics_object
handle, but that's not a *direct* access; moreover a graphic object
is still not bound to its handle at ctor time).

> | >>>>> then the easiest is probably to rewrite properties ctor <<<<<
> |
> | text::properties::properties (const graphics_handle& mh,
> |                             const graphics_handle& p)
> |   : base_properties (go_name, mh, p),
> |     string (new string_property ("string", mh, "")),
> |     //...
> | {
> |   //...
> |   add (string);
> | }
>
> OK, I think this is a reasonable solution.

OK, what do you want me to do now? Should I write a complete proposal
including all specialized property classes, the property generation code
and so on? (this will take some time, of course...)

Michael.