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

[Sandro Magi]

Kamil Skalski wrote:
>
> 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.

Quick overview:

NHibernate loads XML files which describe how a class's fields are
mapped to a database table columns. It loads these mappings at runtime.

However, you're right in that the developer using NHibernate then knows
at compile-time which class is being saved to the database, so
compile-time staging could probably handle this case.

The only cases which this compile-time staging couldn't handle, are
truly dynamic ones where a class is built at runtime, like remoting,
mobile code, or dynamic plugin loading, where you're actually compiling
and/or linking at runtime.

> 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

It's not fast for the first request (unless it's a long-running
request), but it is fast for all subsequent ones of the same type. It's
essentially programmer-controlled JIT, and is subject to the same
trade-offs.

> (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).

Or produce an error message to the user if that's appropriate. In the
serialization example, a System.Object does produces a meaningful result
though.

>> 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.

Right, but there are cases where compile-time knowledge is zero or very
near-zero. They are fairly rare at the moment (except plugins), but I
think that's only because our tools for handling these cases are so poor
that no one would attempt it (like mobile code - although Javascript in
browsers is a form of mobile code, as is SQL, so that's not entirely
true either).

How would you handle serialization of a plugin with a compile-time
macro? Let's assume this contrived example is actually useful for some
reason, ie. user is dynamically loading a plugin from a website, so the
code must be able to deserialize it at runtime.

The plugin's public interface may be known at compile-time, but the
internal structure can not be known, as the end user is specifying a
class unknown at compile-time. This is a truly dynamic situation.

Sandro