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

[Kamil Skalski]

2007/1/7, Sandro Magi <smagi at higherlogics.com>:
> Kamil Skalski wrote:
> >>
> >> 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.
> >>
> >
> > This is not a very good example, since you need to instantiate the
> > object to use reflection on it. I would probably just send the ready
> > assembly over the wire and place some "Deserialize (byte[])" method in
> > the interface.
>
> Yes, you need the class/assembly, but regardless, you still need to be
> able to populate the fields, and this requires runtime reflection and
> compilation/code generation. I'm not sure why it's not a valid example.

Why should you generate this code if you have the author's assembly at
hand and you can force him to implement it on his side?

>
> > Then I could use serialization implementation provided
> > by assembly (and generated at compile-time on the client/provider of
> > plugin-side) to instantiate fetched data into objects.
>
> The end result is the same. You're trusting some dynamic code generation
> algorithm which isn't statically checked. Metaphor gets you at least
> part way to static checking this code generation.
>

Right, if you want to enforce your own algorithm of populating
fields... But it doesn't make much sense, since the implementor of
interface knows better how he wants to serialize his objects. Maybe he
wants to omit some fields or compute the values basing on the others.
It is much better design to avoid runtime code-generation in this and
other similar cases. Also the security does not seem a good argument
here, because you need to execute code from the plugin anyway.

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