## 2017-08-16 Playing with the new "bind" operator...

Since, we work with general HTMLElements most of the time in Lively4,
we do not have the luxury of defining our own API, as we could do in Lively Kernel.

```
var m = new Morph()
m.getPosition() // pt(0,0)
m.setPosition(pt(100,100))
```

Instead we have to fall back to a functional approach:

```
import util from "my-utils.js"
var m = document.createElement("div")
util.getPosition(m) // pt(0,0)
util.setPosition(m, pt(100,100))
```

This approach solves the issue of beeing able to define your own API, but does not fit into an object-oriented writing code flow... since one has to jump around from right to left while writing and reading code. 

With the new binding operator, we though this can be mittigated. In our example, we could evenually write code like:

```
m::util.getPosition() // pt(0,0)
m::util.setPosition(pt(100,100))
```

This code elimantes the jumping from left to right problem, but one has to provide your own `util.getPosition` funtion. 

### Idea: Domain specific util objects

Using objects that name the aspect and then a short function name:

```
var pos = {
  get: function() {
    return lively.getPosition(this)
  },
  set: function(p) {
    return lively.setPosition(this, p)
  },
  getX: function() {
    return lively.getPosition(this).x
  },
  setX: function(x) {
    return lively.setPosition(this, lively.getPosition(this).withX(x))
  },
  getY: function() {
    return lively.getPosition(this).y
  },
  setY: function(y) {
    return lively.setPosition(this, lively.getPosition(this).withY(y))
  }
}
```

That way, one has to not import every little method one want's to call. Or in our case funcition we want to apply, but we can get whole *packages* and the code reads nice. 

```
that::pos.get()
that::pos.setX(100)
```

## Idea: Proxy/Facade Function

We could even go further and use a facade around our element. For example a `Bounds` facade could provide a nice API for getting or setting the position, but also could give direct access to `x` and `y`. 


```JS
class Bounds {
  constructor(target) {
    this.target = target
  }

  get pos() {
    return lively.getPosition(this.target)
  }

  set pos(p) {
    return lively.setPosition(this.target, p)
  }
  
  get x() {
    return lively.getPosition(this.target).x
  }

  set x(x) {
    return lively.setPosition(this.target, lively.getPosition(this.target).withX(x))
  }
  
  toString() {
    return "" + lively.getBounds(this.target)
  }
}

export function bounds() { return new Bounds(this); };
```

```JS
import { bounds } from "utils.js";

that::bounds().pos // pt(100,-111.458)
that::bounds().x = 100
```

```JS
import { array } from "utils.js";

arr::array().last;
arr::array().last = 100
```

### Discussion: Import each used method vs Import API facade

When importing each method (in the implementation a function that is bound), the code looks much cleaner through the binding operator, but one has to define every method that is going to be used in the code in the header.

This could be improved via better tool support: On entering a binding operator, the corresponding import could be lokked up and automatically imported. (This would maybe feel like automatically inserting local in Smalltalk)

```JS
import { last, sortBy } from "utils.js";

arr::sortBy((ea => ea.name))::last();
```

When using the proposed API facade, one can reduce the number of import to only some "domains", but has to write more code on every call and the code is less readable. 

```JS
import { list } from "utils.js";

arr::list().sortBy((ea => ea.name))::list().last;
```

But, when it comes to API that provides getter and setter, Jens thinks that the code looks better with the facade API as shown in the bounds example.

### Binding Operator for Type Conversion (vs Facade)

Its not the same!

```JS
function asArray(a) { return Array.from(a); }

set::asArray()::sortBy(sorting);
```