Re: Graphics properties as objects

[Michael Goffioul]

On 1/2/08, John W. Eaton <address@hidden> wrote:
> | Thanks for the explanation. So, if I understand right, this approach
> | would allow very elegant ways to implement get/set by using virtual
> | functions and the all_props map, while still maintaining the ability
> | for c++ code (e.g. the renderer) to access the properties using their
> | "native" type, not going through some dynamic_cast ?
>
> Given that the above get function returns an octave_value object, then
> no, you'd still have to extract the real type from the octave_value.
> The current code in Octave avoids that by having individual get_X
> functions that return the specific property type.

Actually, the "get" example I gave was not intended to be used by
the C++ backend, but by the octave interpreter to implement the
"get" function. In that case, returning an octave_value is OK. For
the C++ backend, I kept the specific get_X functions that return
a specialized class of base_property (and each of those specialized
class would provide easy access to the property content).

> I understand that having the base class and usinga std::map object to
> store properties allows the get and set functions to be simpler, but
> I don't see a way to use that and avoid the type extraction/casting
> problem.
>
> I see no problem with having a map for user-defined properties
> for which we can't know the type in advance, but for the properties
> which have well-defined types, I think we should take advantage of
> that extra type information.

That's exactly what I tried to do in my proposal. To be precise, I tried
to combine 3 considerations:
1) use a uniform property approach (in class description and storage)
in order to simplify access from the interpreted code
2) use a specialized/typed property approach in order to simplify the
C++ backend code (specialized classes can also automatically
implement property value checking during "set")
3) use automatic reference counting to avoid memory leak

I considered several possibilities (see below), but I couldn't find the
perfect one. The one I proposed seemed to me the best trade-off.
The other possibilities I considered are the following:

1) store well-known properties with specialized classes as it is now
in the octave code, and store unknown/dynamic properties in a
separate map in base_properties (with a "property" class for automatic
reference counting); what I didn't like in this solution is the fact that
it makes getting/setting property by name (== from interpreted code)
unnecessary comply: to look for a property, you have to check first
*all* well-known property, and if not found look into the map in
base_property; moreover, every new object would have to reimplement
this behavior with its own set of well-known properties

2) store well-known properties with specialized classes as it is now
in the octave code, but also register them in the map for all properties;
here the problem was object deletion: whatever the scheme you use
(map<string,base_property*> or map<string,property>), some properties
will have to be deleted (the dynamic ones) and some will not (the
well-known ones, because they are also stored in the owning object)

3) do not store well-known properties and keep everything in the
map for all properties: not really wanted as we want to keep *direct*
access to well-known properties

In the end, the option I proposed is the following: store the well-known
properties with unified class ("property"; hence you always keep a
rerefence to "rep" while the graphics_object exists) and also register
them in the map for all properties (hence make it easy to implement
get/set-by-name). Finally, implement direct access by re-casting the
"rep" field of the unified class. I don't find this re-casting very elegant,
but as I say, I thought it was the best trade-off. I'm of course open to
any other/better solution.

Michael.