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
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