[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: color & radio classes
|
From: |
Shai Ayal |
|
Subject: |
Re: color & radio classes |
|
Date: |
Fri, 1 Jun 2007 12:34:24 +0300 |
On 6/1/07, John W. Eaton <address@hidden> wrote:
On 1-Jun-2007, Shai Ayal wrote:
| To handle raio values you need to pass the construtor a list of the
| allowable values. I see 2 ways to do this wiht octave_values:
| 1) constructor with 2 octave_values one for the color_values and one
| for the radio_values
| 2) a cell/struct octave_value
|
| Is it essential that we have such a constructor? (wih only octave_values)
I think so, because it is the constructor that will be called from the
set function:
class line : public base_graphics_object
{
public:
class line_properties : public base_properties
{
public:
...
void set (const property_name& name, const octave_value& val)
{
...
else if (name.compare ("color"))
color = color_property (val);
...
}
...
};
...
};
Either that, or the set function will have to do the parsing. I think
it is better for the property constructor to do it.
why not define
color_property& color_property::operator = (const octave_value& val)
and then do
color = val
this seems advantagious since we won't have to keep pasing the set of
valide radio_values to color. It will be defined once in the object
(i.e line) constructor, and from then on, it will only be assigned
using the above operator. This hsould also be done for the
radio_property class since they are both unique in that the
constructor also defines the set of allowable values.
If this is ok by you, I will write it up.
Shai
p.s. There some trickiness to it since "r" could be both a valid
color_value and a valid radio_value but I think we should give
prefernce to color_values in this color_property class.