On Wed, 2008-02-13 at 17:09 -0300, Leonardo Uribe wrote: > Hi > > The problem is if the parent class is generated and has package scope, > the code that call the setter (setValueExpression) fails. If the > parent class is generated, this class should be public.
So to work around the "cannot use reflection on package-scoped class" problem we discussed earlier, you are proposing to make the hand-written class package-scoped, and generate a public concrete class? That does solve the problem in many cases. But it means that the hand-written class can never itself define any method in the public API. Any code that it implements itself will be overridden by the generated class. Or do you look for hand-written methods on the parent and generate a public method on the concrete class that simply delegates up to the "real" implementation? Hmm..yes, that looks like it might solve the reflection issue. It is still impossible to reflectively inspect the parent class then call methods on it but for any given method name, there is no implementation on the parent that will not first match a method on the child. However the hand-written code can never reference any of the generated methods, except by (ecch) downcasting the "this" pointer! And code on the parent for method foo() cannot fall back to the default implementation via super.foo(). Aren't these issues a problem? Regards, Simon
