Graphics properties as objects

[John W. Eaton]

On 29-Dec-2007, Michael Goffioul wrote:

| Thinking about graphics properties and how they are currently
| implemented (mainly as octave_value field of a "properties" nested
| class),

I consider that to be a temporary solution and was done because of a
lack of time to do anything better.  The current plan is to convert
most of them to more specific types and do more type checking at the
point of setting the property value.

| I was wondering if it wouldn't be better to define a set of
| property classes as wrappers around the actual property value
| (using the same pattern used elsewhere in octave: a graphics_property
| class with a base_graphics_property "rep" field, and a set of
| concrete classes deriving from base_graphics_property). This is
| the system I used in JHandles. I see several advantages:
| 1) you can use these property classes to store data that are specific
| to properties, like a hidden state or a list of listeners
| 2) property typing can be implemented in the derived class, by checking
| the type of the property value to be set (for instance in the
| operator= method)
| 3) having a common type for all properties (graphics_property) allows
| you to define std::list<graphics_property> objects; this might be useful
| to implement dynamic properties (properties added at runtime) in
| the base_graphics_object class
| 4) property classes have already been used for radio or color properties;
| I see this simply as a generalization of the concept to all properties

OK, we currently have

  radio_property
  color_property
  colormap_property
  data_property

As a start, would you like to propose a patch that changes these to be
derived from a base_graphics_property class as you outline above?

jwe