I think this will actually work, and won't require too many changes.
The bind processor can add the Bindable interface to every class that
uses an @Bind annotation. The interface would contain a single method:
public void __bind(WTKXSerializer serializer);
WTKXSerializer#bind() would check to see if the bound object
implemented Bindable; if so, it would walk up the object's class
hierarchy looking for subclasses that implement Bindable. When found,
it would invoke the specific __bind() method defined by the subclass.
Sound right?
On Jun 9, 2009, at 10:15 AM, Noel Grandin wrote:
What I'm saying is that at the cost of some added complexity in the
BindProcessor,
we can (1) bind to subclasses and (2) support binding in untrusted
code.
Greg Brown wrote:
Bound member variables may be private, and reflection code isn't
allowed to set them in an unsigned applet. The bind processor
rewrites
the code at compile and inserts methods into the Bindable subclasses
that can see the private members. So, we need Bindable to support
binding in untrusted code. I'm suggesting that we get rid of it
because we can't use it to meet a common use case (binding to Window
subclasses), and it relies on undocumented features of javac. Also,
the code itself is non-trivial.
Although we couldn't use it in untrusted code, the reflection code
would still work fine, which is why I suggested that we might want to
keep it. However, it doesn't really save the developer that much
work,
so we could just as easily eliminate it.
