Re: Graphics properties as objects

[John W. Eaton]

On  2-Jan-2008, Shai Ayal wrote:

| On Jan 2, 2008 8:10 PM, Michael Goffioul <address@hidden> wrote:
|
| > What the proposed code does not show yet, is the fact that some
| > features could be implemented in a more elegant way: for instance
| > the get method, that could be common for all graphics objects
| >
| > octave_value base_properties::get (const caseless_str& name)
| > {
| >   std::map<caseless_str,property>::iterator it = all_props.find (name);
| >   if (it != all_props.end ())
| >     return (*it).get ();
| >   else
| >     {
| >       warning ("unknown property: %s", name.c_str ());
| >       return octave_value ();
| >     }
| > }
| 
| 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.  Although we
currently have many properties stored as octave_value objects, the
longer term goal is to convert them to more specific types.  Then the
C++ backend can avoid the overhead of checking types and extracting
values.

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.

jwe