John Torjo wrote:
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
Really? Which would those be? I can only think of the "buddy" property of a spin control.
You are thinking of components as only visual GUI classes. Clearly there is a wealth of components, which any good application framework should allow, which has nothing to do with GUI classes but which can be used with a GUI classes or in a data module. Component programming in RAD application frameworks has as much to do with adding non-visual components to a form or data module as it has to do with adding visual components to a form. A typical example is an edit control which would allow validation based on a regular expression having a property which is a pointer to a regular expression component which allows the various possibilities of a regular expression to be also configured at design-time. The end-programmer would drop the specialized edit control onto a form, drop the non-visual regular expression component onto a form ( or data module ), and assign the property of the edit control which is a pointer to a regular expression component to the regular expression component itself. There are endless possibilities in this scenario where disparate components can be configured separately and then united through a property on one of them which points to a type of the other. This can currently be done in all the major RAD environments of which I know. Your "buddy" property is only a minor example of this general RAD programming paradigm.
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.
This can be achieved visually in other ways. That is, once you create a control, you can define (probaly in a easy scripting language) how to group properties together.
Your "easy scripting language" seems like a solution which I do not want to foster on end-users. The usual ability to present properties of a components grouped in a subclass of that component is supported in C++ Builder, .NET, and Java Beans, among the RAD environments which I know well.
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.
You could be right. I need to put more thought into it.
I was making the case of a run-time reflection mechanism as an ideal C++ should pursue in order to promote RAD programming in application frameworks built around C++. Without native C++ for a run-time reflection mechanism it would certainly seem hard for you to do it in your GUI library, but if you could figure out a way, if only within your environment, it would certainly be a coup. But my argument about this was meant originally for Russell Hind in his discussion about possibility providing RAD support via header file parsing. Eddie