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

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

Just a few philosophical thoughts about evolving an interface vs. abstract base class in this concrete situation of Property.

1. Since there's no non-abstract method in abstract Property class, I deduce that there were no "compatible" changes in the history of life of Property since it's creation. I suspect there were very fey changes if any at all. This means that Property's API has lived to the expectations of it's uses (the BeansBinding internals).

2. Property's API is rarely used in high-level custom code. Property instances are usually used as an opaque type-safe references passed to BeansBinding API methods (Bindings.createAutoBinding, etc...), so Property's API is more or less BeansBinding's internal API. There are of course custom implementations of Property out there (Kevin Day), but I suspect they are not usual for major number of custom applications.

In light of the above, what "compatible" changes to Property API do we envision for the future?

Is there a possibility that internal BBB implementation will need to interact with Property instances in a new way that will require adding new methods to Property type? I don't think so. This would be a fundamental change to the Property's definition and behavior.

The only change I can think of is adding utility methods that are just another way of coding static utility methods so that instead of writing:

Bindings.createAutoBinding(AutoBinding.UpdateStrategy.READ_WRITE, source, sourceProperty, target, targetProperty).bind();

One could write:

sourceProperty.bindReadWrite(source, target, targetProperty);

I'm not a proponent of such APIs. Such utility shortcuts are better placed in classes like Bindings and when statically imported, look much the same as above:

bindReadWrite(source, sourceProperty, target, targetProperty);

Regards, Peter