From: Edward Diener (eddielee_at_[hidden])
Date: 2004-11-16 19:48:56
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
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk