I finally found some time to test the decoration. The problem I have right now is that some methods might be final and thus should not be overridden. I have two choices here:
- Change the decoree’s method so that it’s not final.
- Give the method a different name in the decorator and reroute all calls to that new method. The new method still delegates to the old, final method
If the first way works, that might actually be the easiest. Theoretically, the possibility exists that someone might try to override the now not-final method, but since all of these programs will first be compiled with the regular compiler, those things should be caught. I’m just worried that this way might not work.
The second way would most definitely work, but it makes these changes global, i.e. all files have to be changed. That’s a lot more work. Also, it introduces new names, which may have to be hidden later when I try to fix reflection.
Talking of reflection: The change to
ProperObject might be a lot harder to pull off than I originally thought, at least if reflection is used. Right now it seems like I have to modify
class Class and
class Constructor so that whenever a request for a new
java.lang.Object instance is made, a new
ProperObject is created. Furthermode,
ProperObject.getClass() should really return
java.lang.Object.class, but that’s not really possible:
Object.getClass() is native and final. Ugh.
class Class will probably have to be hacked, too. The idea is to always work with
Object.class but always create
ProperClass.class. I just don’t quite know how to do that yet.
I think I might ignore that for now and push on. Reflection on
java.lang.String is probably pretty rare.