Expressions in bindings

[thejohnfreeman]

We should make an effort to support expressions in bindings.

It is important to note before the below discussion that we cannot know the type of an option value---e.g., normal function vs variable vs other type---before running the binding monad. We can, with the help of a parser, know if it is a function expression vs an identifier vs something else, but that might not be enough: a plain identifier could name anything.

To support expressions, they could be wrapped in a computed variable:

var option = hd.computed(function () {
  return <expression>;
});

Consider each kind of expression:

• constant: The method is only ever executed once. Event handlers are created but never needed and only used to initialize.
• function expression: If the binding, e.g. click, expects an event handler and not a variable, then this creates a problem. The binder has to subscribe to changes on the variable with a response that detaches the old handler and attaches the new handler. Do we want to support a use case where function expressions change?
• variable read: A new computed variable is constructed when the variable could be used directly.
• method call on a member of the context: Is the method returning a constant or a variable?
• other expression: Does the right thing. :/

[thejohnfreeman]

Another case:

• method of an object: Should result in a function with a bound context.

[thejohnfreeman]

Revisiting the function expression / method expression cases:

• function expression: nameOfFunction HotDrink should turn this into a function where this is the current context and the parameter is $this.
• method expression: nameOfObject.nameOfMethod HotDrink should turn this into a function where this is the object named and the parameter is $this.

These functions might be subscribed to events, and as such will receive an event parameter. They should be sure to wrap the functions specified by the programmer so that the programmer's function gets called with $this.