[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Graphics properties as objects
From: |
John W. Eaton |
Subject: |
Re: Graphics properties as objects |
Date: |
Wed, 02 Jan 2008 14:36:51 -0500 |
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
Re: Graphics properties as objects, John W. Eaton, 2008/01/02
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/03
- Re: Graphics properties as objects, Shai Ayal, 2008/01/03
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/04
- Re: Graphics properties as objects, John W. Eaton, 2008/01/04
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/04
- Re: Graphics properties as objects, John W. Eaton, 2008/01/05
- Re: Graphics properties as objects, Shai Ayal, 2008/01/05