Matt, > That makes sense assuming you know how to 'replace B'. That is the > step I am unclear on. I thought that the JVM did not generally allow > you to replace a class with a new definition of it (although I could > be mistaken).
In debug mode some JVMs allow classes and/or methods to be replaced. Sometimes the class can only be replaced with a class that has the same signature, e.g. Sun's JVM. > One could insert some amount of magic checking at the beginning of > methods to handle this case: I am far from a Ruby expert, but my reading of remove_method is that it removes the method from the class but not from super classes. Therefore if the method that is removed is in a super class at compile time then you should call the super class version, i.e. replace method body with: return super.name( ... ); You have to treat Mix-ins like super classes. If the method isn't in the super class or in a Mix-in at compile time then you call added_method, in case the method has been added since compilation and/ or the method is to be added back into the class. Therefore I don't think you need to keep track of which methods have been added or not, you are either calling a super method or added_method. Cheers, Howard. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
