[nem-en] Metaphor, staging, typed reflection
Kamil Skalski
kamil.skalski at gmail.com
Sun Jan 7 00:11:44 CET 2007
>
> > if you are doing
> > something dynamically, it is not really important that part of your
> > job is a little bit statically checked. We do all this at
> > compile-time, which allows you to inspect generated code and in
> > contrast is more flexible than Metaphor approach.
>
> Indeed, some safe dynamic programs will fail to type-check; it's the
> trade off with any sort of static type safety.
>
I was rather referring to the problem of possible failure in dynamic
programs, not possible to catch by such system. I think that the most
common usage of reflection is in totally dynamic context (the paper
divides its use-case into three groups: static - typeof (A),
semi-static - x.GetType() and dynamic GetType ("anyname") where you
have absolutely no guarantee about types of members in object
hierarchy. In such context the typing constraints will simply have to
be disabled to execute code generation or will fail on some casting.
What I really consider bad is that it happens at run-time of you
program (that is not during development / tests, but during
production). That is why I think that making static ensures about
dynamic code generation is quite interesting, but rather not very
useful.
BTW, I am a great fan of static-typing and I consider Metaphor's
system MUCH better than doing similar things by pure reflection with
some textual code generation, which is on the other hand the most
common technique used these days in C# and Java. So my points should
always be placed in context of Nemerle's availability, which offers an
"effectively" safer solutions.
--
Kamil Skalski
http://nazgul.omega.pl
More information about the devel-en
mailing list