Howard~
How does this approach handle redefinition of a compile time method?
What about removal of one?
Matt
On 10/7/07, hlovatt <[EMAIL PROTECTED]> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
