Daniel James wrote:
> In article news:<ni%Wj.135278$Er2.10925@[EMAIL PROTECTED]
>,
> Edward Diener wrote:
>> The most obvious case for run-time introspection is RAD programming
>> in C++, aka design-time programming for properties and events.
>
> Sorry, I feel I have to but in here ... IMO your view is unsup****table
> on a number of different levels:
>
> In the first place, the design-time requirements of a RAD system
> should not be confused with the run-time requirements of the
> components used. Sure, you need some sort of metadata to describe how
> the component looks and behaves but those data do not have to be
> obtained by calling one of the components and asking it what it knows
> about itself. It is only very occasionally that one wants design-time
> behaviour to be present in an application at runtime, and omitting it
> can reduce bloat considerably. OTOH it is quite common for a vendor
> to wish to be able to supply run-time-only versions of components -
> and the logical separation of design-time and run-time features eases
> this considerably.
In RAD systems the properties and events of a component can be queried
from the outside, strings describing those properties and events can be
saved as resources or injected in source code, and therefore those
properties and events can be set on an object at run-time automatically.
In order to do this on an arbitrary object some sort of run-time
reflection is needed by the design time program/environment which is
manipulating the components at design time.
The whole point of this procedure is that design time information is
automatically carried over to the run-time environment. If you do not
see the im****tance or effectiveness of this, then I can not convince you
of it other than to tell you to try a RAD environment like Visual Studio
or C++ Builder. I will only say that in a component-oriented environment
this automatic wiring of properties and events is a great programming
timesaver, but I am well aware that a great majority of C++ programmers
still want to do everything by hand at run-time. Each to their own.
Finally it is perfectly possible to separate the design time and
run-time versions of components, so that only the run-time version is
****pped when a dependent module is linked to the component. This has
been done in C++ very effectively in the past in C++ Builder and a
little less effectively in .Net, but it is always possibly to do given
that the design time environment for a component can be in one shared
library while the run-time environment for a component is in another
shared library. This is not rocket science and already has prior proof
to it.
>
> In the second place, the use of language-sup****ted introspection to
> provide design-time sup****t in a RAD system limits the RAD tool to
> using and generating that language alone. Designers of widget-sets
> commonly wish to be able to make their widgets available to developers
> using a wide variety of languages and tools, and they will not thank
> you for tying the design-time functionality to C++ alone.
I agree that this is a limitation for cross-platform and/or
cross-language building of components. As far as cross-platform is
concerned, there are IDE's which can build components which work on more
than one OS.
>
> In the third place, code in that I have seen in languages that do
> sup****t introspection has seldom been clearer for its use. In an
> alarming number of cases introspective facilities were clearly being
> used only because the designer(s) had been too lazy (or too
> incompetent) to design a workable class hierarchy in the first place.
> Introspection has become a sort of "get out of gaol free" card for bad
> designers. That's not to say that introspection can't be a useful
> tool, just that it seems to be used badly more often than it is used
> well.
I agree that introspection can be misused in places where polymorphism
should be designed. But misuse is never a reason to reject programming
paradigms which have been found to be extremely useful in real-life
programming environments.
>
>> The obvious success of RAD IDEs built from Java, .Net, and C++
>> extensions ( C++ Builder, QT ) in these areas, all with run-time
>> introspection, show the im****tance of this facility.
>
> Yes, introspection can be used quite effectively in Java -- but are
> the solutions that use it good ones? Pragmatically you may say "yes"
> because they generally work, but in many cases they seem to be to be
> bodges that have been put in place for want of a well thought-out
> design. The use of introspection in Java RAD tools does lead to
> usable RAD tools, but I believe that better tools could have been
> built with little or no extra effort if a system had been designed
> that used external metadata descriptions of components (doubtless
> using still more of the impenetrable XML files in which Java
> developers seem to revel) rather than saying "hello, what are you?"
>
> I can't speak for .NET because I haven't used it enough, but I don't
> consider the tools used by C++ Builder or Qt to constitute extensions
> to C++ or to provide what is normally meant by the term
> "introspection" -- Qt programs, at least, can be built with a standard
> (unextended) C++ compiler. Both use metadata outside the C++ language
> to describe component behaviour, much as I recommended above.
>
> For RAD development, what is needed is a standard for publication of
> GUI (and other) components in a language-neutral (and if possible
> platform-neutral) way. If such a standard were to be adopted by
> multiple vendors, with bindings to multiple languages, it would do far
> more to ease the process of RAD design, RAD development, and the
> provision of RAD tools for C++ than would adding introspection to the
> language.
Your qualms are well taken but you are talking very idealistically
whereas many programmers use RAD IDEs simply because they make
programming, and the wiring between components, much easier.
If one sits around and waits for the blessed, ideal IDE eternally one
never gets anything done.
>
>> Unfortunately the standard C++ committee has been nearly oblivious
>> to the benefits of run-time reflection so C++ will almost certainly
>> continue to do without it, much to C++'s own loss.
>
> Introspection does not come for free (any more than does RTTI), and
> there is a principal in C++ that you should only pay for what you use.
> Adding introspection to the language would be a violation of that
> principal, and as such I'm dead against it.
And if one could choose to use it or not would you still be dead set
against it.
Clearly C++ could add introspection to the language but also mandate
that compilers were free not to generate the necessary data for it to
work based on the end-users wishes at compile/link time. I assume that
extra data generated is what your objections are when you say that you
would be paying for its use even if you did not use it. Other than that
I do not believe that programmers not using a C++ introspection facility
would pay for it in extra code size or slower code speed if they did not
use it in any way.
If the "paying for it" involves slower compile/link times, so be it.
Template metaprogramming, which is the closest C++ comes to some measure
of compile time reflection, can incur a huge cost in compile/link time
but I know of few C++ programmers willing to give up the libraries using
it ( Boost etc. ) in order to just save compile/link time.
C++ has come to be fanatical in its unwillingness to consider new
features under the banner that "programmers should never pay even the
smallest iota for some feature they do not use", while other more
flexible languages have moved forward to adapt language paradigms which
help programmers achieve programming tasks more easily.
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
