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