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

[Scott Allen]

On the MS side at least, you can rewrite IL code to dynamically add new
types, or add new methods to a type, using the profiling API and
intercepting JIT requests from the runtime. The assembly does need
permissions to execute unverifiable code, so it is of no use for =
production
code, but could be useful for debugging and certain types of
instrumentation.


-----Original Message-----
From: mono-list-admin@lists.ximian.com
[mailto:mono-list-admin@lists.ximian.com] On Behalf Of A Rafael D =
Teixeira
Sent: Wednesday, September 24, 2003 3:44 PM
To: thomas@thomassondergaard.com
Cc: mono-br@redesolbrasil.org; mono-list@ximian.com

>From: "Thomas Sondergaard" <thomas@thomassondergaard.com>
>
>Can a .net class be changed at runtime? Can you add/remove methods and
>fields at runtime?

I don't think so, because that makes the runtime's security features =
near=20
worthless.

>If one were to compile a dynamically typed language like Ruby or Python =
to
>IL and the classes were to be directly represented by .net classes and =
not
>.net objects this would be necessary.

Every changed object, must be a subclass so they can be assignable to=20
superclasses, but gives entree to an important restriction: you can add=20
things, and override virtual methods, but you can't  subtract things =
(public

ones I 'm saying, you can hide protected itens, and can't even know what =

private things are).

That is specially true for Ruby, where instances of the same type can =
end=20
with different sets of methods. Aggregation  also is part of the=20
magic-behind-the-curtain, to make Ruby's interface addition carrying=20
implementation (I can't remember the name of this feature now).

>I have been using the emit API but this just adds a new assembly either =
to
>memory or a file, so I don't see how I can use it to dynamically change
>existing types.

You can't, you can only create new ones, as I said before.

>In CIL you can call a virtual function. This, as far as I understand, =
is=20
>the
>limit to late binding as implemented in .net (without reflection). In =
ruby
>and Python the concept of sending messages to an object is more dynamic =
and
>has nothing to do with types. Using Type.InvokeMember you can mimic =
this
>behaviour on .net but could it is relatively slow. Why not add a new
>instruction to the CLR that is simply called e.g. 'send_msg'  that =
accepts=20
>a
>methodName string and a list of parameters? This would be essential for
>dynamically typed languages wouldn't it.

That is the problem of security again:How do you verify that some code =
is=20
safe for execution, and throw exceptions when it tries to use=20
policy-forbidden features, if it is totally changeable at runtime?

>Disclaimer: I don't really know much about this I'm just wondering what =

>kind
>of platform support that is necessary if you want dynamically typed
>languages to execute more or less directly on the CLR, meaning that =
classes
>are represented by .net classes and not .net objects.

I think dynamically typed languages are hard to fit  inside a .NET, =
period.
But don't get stopped by it.

>Cheers,
>
>Thomas

Regards,

Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001

_________________________________________________________________
MSN Messenger: instale gr=E1tis e converse com seus amigos.=20
http://messenger.msn.com.br

_______________________________________________
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list