> AFAIK, it's VM-dependent how far it's supported. In the Sun VM, you
> can swap a class if the method body is changed, but if method
> signatures are changed, or fields are added or removed, the change is
> rejected.
This is probably sufficient, imagine each JRuby class including
JRuby's Object class inheriting from:
abstract class AbstractJRObject {
List< JRObject > addedFields = null; // Used to store references to
fields added at runtime
JRObject addedMethods( int methodID, JRObject... args ) {
// call missing_method and add new method if that is what
missing_method does
// return the value from the new method
}
// other methods from JRuby's Object class that are known at compile
time
}
Then in a JRuby's Object class you initially have:
class JRObject extends AbstractJRObject {}
But when at runtime a method with id 123, say, is added JRObject is
replaced with:
class JRObject extends AbstractJRObject {
JRObject addedMethods( int methodID, JRObject... args ) {
switch ( methodID ) {
case 123:
// body of method
break;
}
return super.addedMethod( methodID, args );
}
}
Methods known at compile time are called via object.name( ... ), but
methods unknown at compile time are called via
object.addedMethod( methodID, ... )
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
