Re: Announcing Xrtti - Extended Runtime Type Information for C++
On May 5, 8:20 am, bji-gg...@ischo.com wrote:
On May 5, 10:47 am, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
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?"
[snipped]
You seem to be getting hung up on the fact that there are a variety of
approaches to solve many problems. It sounds like you think there is
just one way to do things, and that is a way which somehow doesn't
invoke any other simplifying technologies. This is not true. As
developers we write not only software, but tools that help us to write
software. Xrtti is in the latter category; it is a tool. You use it
where it makes your job easier. You don't use it where you would
rather solve the problem a different way.
Please note that I was not discounting RTTI, or XRTTI, I was
discounting a certain style of programming that you alluded to as one
example use of XRTTI. For example, if XRTTI could have standardized
the naming of objects for better serialization of polymorphic objects,
I would thing that is quite beneficial. You use a word in the
preceding paragraph: "simplifying".
The question I was asking was, "Does it actually make the code
simpler?" Does the use of reflection to "test" member functions of
classes result in less or more complexity overall.
You wrote in a another post in this thread:
"I haven't tested this code, I just wrote it out quickly, and there
are
probably bugs and typos. But it illustrates the general technique you
would use to do this. The hardest part by far is having an algorithm
to "make up" test method arguments. I would expect that this would be
something you'd have to supply some kind of configuration file for. "
Hmmm..."The hardest part by far is having an algorithm to 'make up'
test method arguments." I agree. It's called artificial
intelligence, and it does not exist yet. If it does not exist, then
the 'making up' must still be done by a human: "I would expect that
this would be something you'd have to supply some kind of
configuration file for." So here, I suspect that the "supplying" of
configuration file is done by a human.
Now imagine. The whole idea was to get the code correct, the C++ code
that its. So you add reflection, then hunt your classes for test
methods, then rummage through you code and find all of the valid and
invalid values for arguments that could be supplied to your functions,
then put specifications of what those arguments can be in a
configuration file, along with the test methods. Of course, one must
anticipate that, in general, the argument set of a function is
arbitrary. The values are not necessarily linear. They can be pseudo-
linear, broken range, limited to a specific set. For a given function,
the "state space" of the set of arguments might be valid only for
particular vectors in the state space, and not for others. Invocation
of functions might only be valid after prior invocation of other
functions.
By the time you have created a framework to provide any useful model
for the average programmer to "automatically" his code, you will have
created an entirely new language just to to be able to describe what
is to be done in the configuration file, plus and compiler/interpreter
to evaluate the information.
This, IMO, is silly. Even though the compiler/interpreter would be
created only once, the configuration file would have to track ever
single change of type signature of a function. You'd end up
programming in two languages: C++, and a mini-language to track what
you have done with your C++ code.
And you think this is simpler than focusing on good form in C++ code
in the first place and using traditional testing methods?
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]