Op Sat, 14 May 2011, schreef Joerg Schuelke:
I think of this a little different. Maybe more from an other perspective. For me RTTI is a level of language extension. Like OOP, or generics, or inheritance. Macros are very low level (if you have them).
RTTI *allows* for language extensions, like str/val for enums. RTTI by itself are just data structures describing Pascal types, emitted automatically by the compiler. Language extensions can use those data structures to provide their functionality.
It is not that I think that I would use a macro instead under all circumstances. But it should be possible to do it without RTTI which is of higher level in the language.
I still don't see why it should be possible to do it without RTTI. But the question is, is the unknown reason that you don't want to use str a justification for adding the can of worms that is called macro's?
The principle is do not use it if you do not like it. That should not influence the rest of the language. This way I think that it is not that bad to have a small, but powerful macro expander incorporated.
It's not that bad, but it should make something possible. Until now I haven't seen many bright examples of things that cannot be elegantly without macro's.
52 bytes of data. And the RTTI code?
Not much. Converting an enum to a string is a single procedure. It's quickly won back if you use the feature a few times. Actually this is a nice story about the hidden costs of language features. The procedure would be extremely simple (lookup a pointer to the string in an array, return the string), but FPC supports non sequential enums:
type colour=(red:=1,green:=10,blue:=100);The majority of the code in the procedure that converts an enum to a string deals with handling this special situation (don't worry: normal enums are still a simple lookup). Often when you add features, it has unforseen consequences and it can be a complicated effort to make everything together well enough. This is why you want to be carefull adding new features.
What if you do not smartlink?
Then you get so much extra code in your exe that the RTTI is still a small and irrelevant portion. Actually in the past you could disable RTTI generation, but it was too sensitive for bugs. Removing unused code & data is the task of the linker, we decided to make the linker do what it is designed for.
I repeat, I have really nothing against RTTI, but I state that it comes from a high level language extension.
Good.
By the way this RTTI thing comes from the argument: Do not use a macro, instead do it this way. But this forces me to use RTTI, which is possibly not what I want.
Hmmmm... For the same reasoning you could say inline functions are ugly and you want not to be forced to use inlining.
The point is that every time you can avoid a macro you win on code clarity, compiler speed (no time spent on evaluation & expansion), debugability, parsability by IDE's, and so on.
Inlining is better that doing the same with macro's, so is the use of str/val better than macro tricks.
We don't want to force you to use RTTI, but our point is that there is proper solution to achieve the same benefit that the macro approach gives.
But this way I can show you even OOP is useless :) what I do not believe.
While I do believe in the merit of OOP, there are many dubious OOP features that you can criticize in a valid way, escpially because few of those features open new possibilities. But unfortunately it's a waste of time; we need this for compatibility.
Daniël
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
