SPAM-LOW: Re: [nem-en] Metaphor, staging, typed reflection

[Kamil Skalski]

>
> I believe you are referring to Page 10:
>
> "If however the type to be serialised is not statically known then the
> serialiser can only be invoked through a dynamically-typed invoking
> function [...] Although the invoking function is dynamically-typed, the
> code inside it is not (except for the initial cast). The purpose of the
> cast is to prevent an object of the wrong type from being serialised."
>
> Of course, this is no worse than currently deployed solutions in C# and
> Java, and much software designed in this way is still quite useful.
>
> Full knowledge isn't possible in such situations anyway. Take an O/R
> mapping tool like NHibernate for instance; NHibernate must be able to
> dynamically serialize an object to a relational table, and the type of
> the object can *never* be known ahead of time.

I'm not sure this is true. There is always the "design" stage during
development, where you know everything about your objects and
data-base. But I don't know exactly the workings of  NHibernate - if
it indeed has places where it *needs* to generate code at runtime and
only then it has the required knowledge about objects / data-base,
then I just wouldn't like to use such system.
And note that I mean real "runtime" - e.g. user clicks in a shop
application and then your server compiles some code to handle this
request... This doesn't seem fast or safe (by means that even if you
have those iftype and GetFields<A,B> you will most probably need to
handle System.Object case and have the default handler, which will
throw exception or produce some garbage).

>
> The benefit of writing NHibernate in Metaphor is that staging the
> serializer means each type will "automatically" receive a
> specialized/partially-evaluated serializer which will be JIT compiled,
> and thus quite fast. Only recent releases of NHibernate have just such a
> JIT-compiled "serializer", and it had to be written manually using
> Reflection.Emit.

I agree - this is a very good incremental approach to make things better.

>
> > 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.
>
> I haven't developed with Nemerle's macros, but I haven't seen anything
> that indicates they are safer. Except perhaps in the sense that
> compile-time macros limit one to compile-time staging, thus potentially
> reducing runtime errors. Is this what you meant?

Yes, exactly.

>
> If so, how would a Nemerle macro handle the generic serializer example
> such that it would be safer than that provided in the Metaphor paper?
>

Designer could ensure that all his serializers compile/generate fine
and does not hit any "impossible" case in his code. This is something
like automatic testing framework for all used cases of code generation
in your app.
Of course there is always a temptation to generate code at runtime /
JIT, where you indeed have maximal knowledge, but I consider it a bad
design.

-- 
Kamil Skalski
http://nazgul.omega.pl