[Mono-devel-list] Re: Dynamically changing classes?

[Thomas Sondergaard]

> Problem: it doesn't handle updating existing class instances.  Thus,
> this may be unsuitable for some situations.

Yes it is a trick and it is nasty. I think it is fair to conclude that the
current class model in .net is not friendly to the idea of classes that
change their interface and/or implementation at runtime.


> Why add a new CIL instruction, when you can just do it yourself?
>
> interface IDynamicLanguage {
> public object Invoke (string message, object[] args);
> }

That looks oddly familiar. This is from my ScriptingExtensions project,
which I use for rubydotnet, my ruby/.net language binding.

namespace ScriptingExtensions {

    public interface IObject {

        object send(string message, object[] args);

    }

    public interface IProc {

        object call(object[] args);

    }

}

> Just have all your internal classes implement IDynamicLanguage, and you
> get the same functionality as "send_msg".  There's no particular reason
> why this has to be in CIL, as opposed to doing it yourself (above).

Not really, by implementing this 'in .net' not as .net you are bound to
execute a lot slower. Imagine compiling this ruby function to .net

class ACLass
    def invokeSomeMethodsOnArg(arg)
        arg.doThis
        arg.doThat
        arg.AlsoThis
    end
end

Ruby is dynamically type so arg can be any type. This means that the only
way to invoke doThis, doThat and AlsoThis is using the reflection API, e.g.
using arg.GetType().InvokeMember("doThis", ....). This will be very slow.
Not only because of the services rendered I think, but because of the layers
of abstraction, which could be done away with if the CLR supported the
concept. The abomination known as method overloading adds complexity to this
issue, unfortunately.

> The ways outlined above would work, but they're not necessarily the
> *best* way to do it.  I'm not sure what the best way is, and I'm not
> sure anyone else knows either, for that matter.
>
> Thus, research and experimentation are required. :-)

So true.

Thomas