Re: Announcing Xrtti - Extended Runtime Type Information for C++
On May 4, 10:59 am, Hyman Rosen <hyro...@mail.com> wrote:
In our company, for example, we're building application
environments which can dynamically pick up component
libraries as they become available. The objects in these
libraries can be interrogated for their properties and
methods, and the environment can then be instructed on
how to hook the components together.
Hmm...well..you hit the nail write on the head..this is what I meant,
this style of programming. ;)
Because computers are not artificially intelligent, I have serious
doubt that the model can be so generalized that you can drop in any
component and let the environment figure out how to twiddle its
functions. Functions take arguments, and arguments have allowable
ranges on values, etc. There has to be a contract somewhere. The $1
million questions is: "Objectively speaking, in an absolute sense, is
the framework so generalized, or is it actually something that is the
manifestation of hope, and in fact, contracts are present, and the
same thing could not have be accomplished without reflection?"
We have the canonical example of a component which lets
you pick or type the name of a stock, another one that
receives the name of a stock and produces a table of quotes,
and two others that receive table of quotes and display them,
one as a numeric table and another as a graph.
I wonder if it would be possible to do the same thing without
reflection?
Another example is the NUnit testing framework, which is
again able to pick up arbitrary libraries of components and
apply unit tests appearing in those libraries, again using
reflection to interrogate the libraries as to what tests
are present and how they are to be preformed.
What about range of arguments to functions? Must that be specified in
the framework? I could be wrong, but it seems to me that you get to a
point where the test code itself becomes a significant fraction of
code base. If that is the case, then is it not better to spend that
mental effort on getting good form on the code so that you know it is
correct? After all, code has no physical properties. It does not
degrade over time. Once built, the form of the code will remain the
same over a trillion years. Why keep testing it if it is correct? Or
rather, why put the test code inside the component if it is correct?
What is wrong with external unit testing?
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]