An interesting chains of discussions has been triggered about JavaFX features and how it can be possibly used beyond the GUI scope.

Osvaldo has just published an interesting post. Actually I like binding a lot, but I was wondering about some adverse effects that can arise out of binding use.

There is a basic conceptual problem: binding is an evolution of getters/setters, that is exposure of naked properties. According to OO principles it is a breakage of information hiding, that should implemented by encapsulation, but we got used of it because of fourteen years of Java, as most of the Java frameworks use it (not only Swing, but also JPA etc...). So we can live with it - but I'd say I'm fine with it for some mundane uses such as populating a UI or a persistence bean; it would be probably better if we learned to avoid it for core business classes.

Anyway, this is just a general premise; now let's consider a specific example. Consider the following JavaFX class:
class Breakable
  {
    public var theProperty = 0;

    public function breakIt(): Void
      {
        theProperty = 4;
      }
  }
It's fine, right? You can even unit test it without problems, so you declare it stable.  Now, you use Breakable in this context:

var breaker = 1;

def breakable = Breakable
  {
    theProperty: bind breaker;
  };

public function run(): Void
  {
    breakable.breakIt();
  }

Run it, and you get a

com.sun.javafx.runtime.AssignToBoundException: Cannot assign to bound variable

You can't execute theProperty = 4, since theProperty is bound and, by definition, at every moment can only hold the same value as breaker.

Do you see my point? An external class has broken Breakable, that was fine by itself. We have injected a problem. This is a worse breakage than breaking information hiding in Java by getters/setters, as not only we can change the internal status of Breakable (forgivable as explained in the premise), but we changed also the behaviour of theProperty, that now can't be assigned any longer; it is now incompatible with the original behaviour of Breakable.

I'd be worried about using this in a core business class. OO exists to make our software more robust, but binding in this perspective can make it more brittle.

I propose to address this issue by introducing an unbindable keyword such as:

class Breakable
  {
    public unbindable var theProperty = 0;

    public function breakIt(): Void
      {
        theProperty = 4;
      }
  }

This would make the compiler stop with an error when you try to bind theProperty (the problem is unidirectional binding; bidirectional binding is ok). You might think that the enhancement of the compiler could be done without a specific modifier, as the compiler could induce the unbindable status of theProperty by just finding the assignment theProperty = 4; but this is just a simple example, and theProperty could be a protected variable manipulated by a subclass.

This small example can be checked out as a NetBeans project from:

svn co -r 45 https://kenai.com/svn/javafxstuff~svn/trunk/Binding1