Those were the things to say about the 1st redesign:
This project recently had it's first file-release. It's not only the first release, but it's also
the first release after the complete redesign on the project, which had the following reasons:
I gave a more OO-like implementation a chance, because I wanted to compare it
to the previously chosen template-based approach. And... what should I say. I liked it!
The new approach naturally supports runtime-analysis of reflection data instead of
only using reflection information during compile-time. In the old approach,
runtime-reflection would had been possible with significant extra effort.
The template-based approach made heavy usage of
template-meta-programming which takes a lot of time for maintainers and
compilers to understand. So I think I will be much more productive with the new design.
First of all, the ClassType reflector has to be extended, so that it can express (multiple)
inheritance.
Then I think, that there has to be some way to put additional application specific information
on types and class member. This will support something like aspect programming.
Having this information, an application of the reflection library could make decisions based on it.
So it is a tool to put aspects into your software.
With all that I think I will reflect the classes of the reflection library! Sounds cool?! Imagine,
you could send type information across the network and then create an object of that type,
work with it - using the type information - and then send it back to some software that e.g. has
some compiled member functions for that type of object.
Experiment with reflection of functions. Using a library like FFCall makes it possible to call free functions and static member methods. Perhaps I'll find
something to do the rest, AKA (virtual) member-functions.