The solution you sent is really good, and moderately fast on runtime. But the problem for me is that one must keep most of his classes in consistent state almost all the time - at least enough consistent to enable superclass resolution and field finding. Wich is inaccessible for me.
Lets look at the use case:
I know class SuperClass is valid, and declares some protected fields and methods. I want to instrument one of its subclasses' finalize methods to dump those fields on the console; and even may be to invoke some of the protected methods. If the default createGetField(...) was like you offered, and I used it, SuperClass will have to be loaded (or even will be loaded and resolved!) while I am trying just to dump its fields.
I dont mean there is no place for smth like createFieldAccessResolve(...), with the behavior you offer; I even think it would be great, and can be driven to do great job if used with care.
For example, in my project one of the biggest classes (I hate big classes) is MyInstructionFactory; there I place useful codegens like createLd(loadsOfTypes).
Regards cheffo Berin Loritsch wrote:
Stephen Kolaroff wrote:
Well, I must disagree: I think BCEL should not try to foresee "where a developer wants to go today". So the InstructionFactory class (and corresponding Instruction subclasses) will be kept small, fast and clean; for example:
class BaseClass {
protected something;
}
class DerivedClass extends BaseClass{ protected something; }
the above declarations are perfectly correct; and the fields with same name are simply different fields (pls., avoid constructions like this:)). Then:
1. what should be the default field access?
2. How can we trace potentially huge number of classes fast and tricky?
3. And so on.
Same rules as a standard compiler.
getField("something"); if ( null ) getSuper().getField("something");
The biggest frustration is the difference between static and virtual fields.
class Demo { protected something; protected static otherThing; }
Currently both of these require a separate way of accessing them. The first is not static, so we can access it with:
Constants.GETFIELD
The second is static, so we have to access it with:
Constants.GETSTATIC
It is really simple to check the associated Field for whether it is static or not:
javaClass.getField("something").isStatic() ? GETSTATIC : GETFIELD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
