[boost] Re: Re: GUI Library Proposal for a Proposal

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-11-12 17:49:04

John Torjo wrote:
>> You have made a good point. I still feel uncomfortable about parsing
>> header files to determine type information. If header files were
>> used, since run-time reflection does not exist, one would have to
>> inject the correct code into source files based on design-time
>> decisions. But it does seem as
>
> I think reflection in general is very different from reflection for a
> GUI.
>
> When you have a GUI control, you want to apply reflection for a few of
> its properties. You won't have #ifdefs (or at least I would consider
> it bad design). Case in point: its interface should be extremely
> simple and easy to parse.

That is the ideal. I do not deny that in most situations you are correct but
most is not necessarily all. It is possible, after all, to create components
which act differently depending on a number of compile time factors although
it is obviously quite uncommon.

>
> You shouldn't need complex information like reflection for virtual
> functions, overloading etc.

Generally not for design-time programming. I agree.

>
> Even reflected property types should be of trivial types:
> 1. build in types
> 2. std::string
> 3. types that can simply be read from /written to strings.

Here is where we disagree. One should be able to make properties which
encapsulate classes or data structures themselves. It is quite common to
make a property which is a pointer to another component type and allow the
programmer at design time to connect that property to another component
which has also been dropped into the design time environment and configured
separately. Furthermore it is also quite common to make embedded properties
which are themselves small components with their own sub-properties. This
latter is often a good way to organize properties in a way that makes it
easier for them to be understood and set.

Event handlers can also take parameters which are components or classes in
and of themslves. Often a good creation of components, with their design
time properties and events, involves the ability to organize everything
coherently and in an easily understood way. This sometimes necessitates
grouping both properties and events into sub-components and component
pointers. Your idea of "trivial" types sounds nice but to me it is like the
C++ programmers who think they can do all they want with only trivial
programming. It is a nice dream but eventually runs into a reality in which
complexity is actually the correct design.

>
> For case 3., you might also have a validation function which will be
> used in design-mode to validate user input.

Both .NET and C++ Builder allow one to do validation of a component property
at design-time, which is actually run-time for the component. This is
another reason why run-time reflection is better than header file parsing.
One is already in a run-time environment for components when they are being
dropped on a form, so why not use the full abilities of a run-time
reflection mechanism.

>
> At least that's what I want.
>
>
>
> Best,
> John