Re: How can I use unqualified names? (Possibly hard or impossible?)
On Jul 27, 7:44 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Alf P. Steinbach:
* James Kanze:
[snip]
Extensible in what way?
My up-thread usage example's definition was
CPPX_DEFINE_OPTION( x, double )
CPPX_DEFINE_OPTION( y, double )
CPPX_DEFINE_2OPTIONCLASS( Pos2Options, cppx::options::NoBase, x, y =
)
CPPX_DEFINE_OPTION( z, double )
CPPX_DEFINE_1OPTIONCLASS( Pos3Options, Pos2Options, z )
where the last line expresses a base-derived class relationship.
In particular it can not, AFAICS, be used to produce the
two option classes in my example usage code shown earlier
in thread (natural modifications OK, of course), which
you'll see if you try.
I'll look at it, but I'll admit that I've never found any
reason to "extend" an options class. They're normally
one-of sort of things.
So, this isn't the problem you've been dealing with. :-)
Perhaps an example can help you/others understand the intentded usage.
In MainWindow constructor (this is just ephemeral try-it-out code) there =
is
new Edit( *this, Edit::Params()
.text( L"Blah blah" )
.position( Point( 10, 10 ) )
.size( Point( 300, 20 ) )
);
new Button( *this, Button::Params()
.text( L"My button" )
.position( Point( 10, 40 ) )
.size( Point( 160, 24 ) )
.isDefault( true )
);
where the Params passed to the Edit control and the Params
passed to the Button control have the same .text, .position
and .size elements, because they're derived from the same base
general window Params class.
The Params passed to the Button control have an additional
.isDefault, which is not meaningful for the Edit control and
hence doesn't exist in Edit::Params.
OK. I rather suspect that this could have been used in my case
as well. In my case, most of the components shared a very large
set of options, and have few, if any, additional options (one or
two at the most), so we just used an Options class for the
common options, and additional arguments (with defaults) for the
one or two additional attributes, when present. But your
solution seems more elegant.
In class Button the extra .isDefault option is added thusly,
in a nested class ApiWindowFactory:
class ApiWindowFactory
: public Outer::Base::ApiWindowFactory
{
typedef Outer::Base::ApiWindowFactory Base;
private:
bool myIsDefaultButton;
public:
CPPX_DEFINE_OPTION_VALUE( isDefault, bool, false )
CPPX_DEFINE_1OPTIONCLASS( Params, Base::Params, isDefault )
ApiWindowFactory(
Window& parentWindow,
Params const& params = Params()
)
: Base( parentWindow, params )
, myIsDefaultButton( params.isDefault() )
{}
virtual ButtonKind::Enum apiButtonKind() const
{
CPPX_IS_OVERRIDE_OF( Base::apiButtonKind );
return (myIsDefaultButton? ButtonKind::defPushButton :
ButtonKind::pushButton);
}
};
As you can see defining the derived Params with an extra
.isDefault, adding in derived class setters for all the base
class elements (.text, .position, .size etc.), is very very
simple, two lines of code, placed right where the definition
is desired -- and no external script or extra files or ...
:-)
Yep. And my solution doesn't support generating a nested class
(and making it do so would be almost impossible).
I still don't agree with your objections because an extra tool
is used---I'd rather use an extra tool than do extra work
myself. But in this case, you've pretty much convinced me that
your solution does something the "simpler" solution with the
extra tool can't, which is a strong argument in its favor.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34