[BBB-DEV] Re: re: Re: org.jdesktop.beansbinding.Property should be interface

[Peter Levart <peter.levart@marand.si>]

On Thursday 16 July 2009 01:15:49 Kevin Day wrote:
> We do create our own Property implementations (code outside the API), but I could live with Interface + Abstract Base Class as a compromise, if there's a solid reason for making that change.
>  
> My concern, though, is that for the situation that Peter is wanting to use it for (I think - I'm still a little unclear), we would wind up with tons of little implementations of the *interface* in all of our beans, not derived from the base class.

That depends on the internal implementation. There are different strategies.

Using runtime class generation means that generated classes are "compiled" Just In Time which eliminates binary compatibility issues.

1st I was thinking of runtime class generation using javassist. In that case I would surely generate classes that extend Abstract Base Class. But even If using dynamic JDK Proxies, their Handler's could be coded in a way that delegate all Property's method invocations to a real Property implementation which is derived from the abstract base class so that adding methods to interface and abstract base class would not break it.

> A change to the interface would then have massive impact to existing code (code that really never intended to have anything to do with Property - but was just using it as a convenient way of exposing it's properties).

Only if the choosen strategy would generate classes as part of main program compilation (using javac processors for example). But I'm not a fan of that approach.

> I'm pretty sure that having an abstract base class that implements the interface would not address the issue (that would just put Peter right back where he is now, I think).
>  

Not quite so. That would be just fine.

>  
> I'm quite eager to see some examples of how interface would impact his strategy.
>

Property being an interface would enable me to get rid of Props interface (a container for "this" property) and would therefore simplify the syntax of obtaining Property instances where property paths end with a bean that has sub properties.

To be fair, even if Property is an abstract class, I can do this. I can create a special implementation of Property which is subclassable and instead of inner P$ interfaces create inner abstract subclasses of this special Property implementation.

But using this approach I cannot:
- use JDK dynamic Proxies
- use multiple inheritance for P$ types

Peter