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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A Rafael D Teixeira Sent: Wednesday, September 24, 2003 3:44 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] >From: "Thomas Sondergaard" <[EMAIL PROTECTED]> > >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 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 superclasses, but gives entree to an important restriction: you can add 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 with different sets of methods. Aggregation also is part of the magic-behind-the-curtain, to make Ruby's interface addition carrying 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 >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 >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 safe for execution, and throw exceptions when it tries to use 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�tis e converse com seus amigos. http://messenger.msn.com.br _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
