Re: changing genprop.awk to handle radio_values

[Shai Ayal]

On 9/14/07, John W. Eaton <address@hidden> wrote:
> On 14-Sep-2007, Shai Ayal wrote:
>
> | As discussed in previous threads, to set radio_properties and/or
> | color_properties from an octave_value, an assignment should be
> | preformed, not a constructions. i.e.
> |
> | radio_property rp("all|none|quiet");
> | octave_value ov("none");
> |
> | // the right way, preserves the allowed_values
> | rp = ov;
> |
> | // the wrong way, overwrites allowed values
> | rp = radio_property(ov);
> |
> | Currently genprops.awk only allows for the "wrong way" when emitting a
> | "set" function:
> |
> | ##   void
> | ##   set_NAME (const octave_value& val)
> | ##   {
> | ##     set_NAME (TYPE (val));
> | ##   }
> | ##
> |
> | this can be fixed in one of the following ways:
> | 1) don't change genprops.awk, and use an o or O modifier to write a
> | custom version of set
> | 2) make genprop always emit an assignment "set" function:
> | ##   void
> | ##   set_NAME (const octave_value& val)
> | ##   {
> | ##     NAME =val;
> | ##   }
> | ##
>
> I don't think we want to do this in all cases.  The idea was that if
> someone defined a set_NAME (const TYPE&) function that did something
> extra (say setting the corresponding "mode" property) then that would
> happen automatically when calling the version that takes an
> octave_value object as its argument, and it would only be necessary to
> do that in one place (the type-specific set function that is called by
> the octave_value version).

didn't think of that ...

> | 3) add another modifier (say "a") to make genprops emit an assignment
> | set function
> | 4) have genprop.awk automatically emit an assignment "set" function
> | (like in example 2) if TYPE is color_property or radio_property
>
> I prefer either 1 or 3.
In this case I would go with 3. There are quite a lot of properties
which need to be converted to radio values (line marker, line type and
more) so automatic generation would be better.
I will send a patch