Re: legend and bar?

[Shai Ayal]

On 11/6/07, John W. Eaton <address@hidden> wrote:
> On  6-Nov-2007, David Bateman wrote:
>
> | Add an octave_map to base_graphics_object to hold the additional
> | arguments and their field name and methods get/set/add/del methods to
> | the base class to use these additional arguments. Then you have two
> | choices, either all the existing classes for graphics objects can be
> | rewritten to use this map for all fields (which would be the
> | cleanest),
>
> Doing it this way would make all the individual set_X/get_X functions
> somewhat slower as they would have to look up values in the map.
>
> A more important issue (especially when we implement a significant
> portion of a graphics backend in C++ instead of in the scripting
> language) is that values in the map would all have to have the same
> type (presumably octave_value) and I think it would be better for most
> of the fixed values to have specific types so that we don't have to
> extract the specific types every time we need to get a property value.
>
> I know that currently most properties are stored as octave_value
> objects, but this is just temporary, and the goal is to have most of
> them stored in more specific types and also to be validated when they
> are set.  In many cases, the validation can happen in the constructor
> for the specific property type.
>
> | or the get/set methods for each of the graphics objects can hand off to
> | the base class for field names it doesn't know rather than returning an
> | error, which would be simpler to implement quickly.
>
> I think this would be best, though it is not clear to me whether the
> map of properties should be in the base class.  Without looking
> closely at it, it seems that each OBJECT::property class should have
> its own map to hold user-defined properties, but maybe I'm missing
> something about the way the addprops function is supposed to work.

That brings up the natural question -- where can I find the docs for
"addprops"? I we're going to implement it, at least we should be
consistent with other implementations ...

Shai