Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Premise: There's nothing that can be done with run-time introspection that cannot be done (better) by compile-time decision taking. Except that compile-time decision taking can only be done at compile time. And many of the languages that that have no or only limited introspection also don't have a compiler available at run time. Once your framework becomes generic enough, it can become too constricting to force a static interface on its components. And the static interface may even turn out to be slower than the one that uses introspection and related techniques. Consider, for example, an OO-relational mapping layer where the fields are all accessible via methods (or public properties, if you must):
In many languages, this is much faster than the alternative: But when you do need to have generic routines (for instance, to print the contents of some object), you need some functionality like: Otherwise you're stuck with implementing all the "reflection" stuff in the API, which generally means the API will be ugly and slow. Aside: all of this was already well understood and implemented in the 70s with Smalltalk. Why the static OO guys seem to think runtime inspection, "duck typing" and meta programming is something newfangled and scary is beyond me.
In reply to Re: Runtime introspection: What good is it?
by Joost
|
|