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. getName()
, isInstance
, isAssignable
in 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.Object
and java.lang.String
is probably pretty rare.