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

[Jonathan Pryor]

On Wed, 2003-09-24 at 19:24, Thomas Sondergaard wrote:
<snip what="IDynamicLanguage declaration, etc." />
> > 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.

I'm inclined to disagree.  Certainly, using Reflection (right now) is
bound to be slow.  So would using a custom interface; again, Right Now.

Forget about dynamic languages for the moment.  How does .NET handle
String.Length?

	string s = "hello, world!";
	for (int i = 0; i != s.Length; ++i) {
		// do something with s[i]
	}

This *looks* like it will call String.Length "i" times -- once for each
loop iteration.  However, the .NET JIT engine (and mini, AFAIK) looks
for this style code, and caches the result of "s.Length".  The end
result is that the above code is *faster* than the equivalent:

	string s = "hello, world!";
	int len = s.Length;
	for (int i = 0; i != len; ++i) {
		// do something with s[i]
	}

No special CIL opcodes are used; the JIT just looks for this style CIL
and a call to System.String::get_Length().

Getting back to dynamic languages, it seems reasonable to assume that if
we had a standard interface -- that is, one that the JIT knew about --
the runtime could optimize for dynamic languages via message sending,
buy Doing The Right Thing, whatever that happens to entail.

This wouldn't require any additional CIL opcodes, it would just require
adding additional optimizations to the runtime.

It would also require determining under what circumstances the
optimizations apply, how to best optimize them, and implementing those
optimizations.  Again, a research effort. :-)

It may be that adding CIL opcodes simplifies the effort for dynamic
languages, or makes the JIT operation faster, so I'm not going to say
that CIL opcodes are a Bad Idea.  I'm just trying to point out that
adding CIL opcodes doesn't have to be the first attempted solution, that
there may be ways to be friendlier to dynamic languages without
extending the ECMA spec (well, without extending it *too* much; I figure
a new, recognizable interface may be required, but adding CIL opcodes
should be the last resort).

 - Jon