Closed int3 closed 10 years ago
Actually, using sink
on a Behavior (UI a)
is semantically unsound. The question is: How often is the enclosed UI action executed in order to assign the value of type a
? (Remember that UI actions may have side effects.) Behaviors are supposed to be continuous, i.e. there is no way to know how "often" a Behavior "updates" and hence no way to figure out how when the side effects are to be executed. (This is a design decision: Code that does not depend on the frequency of updates is easier to reason about.)
The bindAttr
is more imperative in style, and hence doesn't have this problem. Still, I would prefer not to add it in order to discourage use with Behavior (UI a)
.
Ah, I see. Thanks for the explanation!
Right now it is awkward to directly invoke
sink
on thechildren
attribute, becausesink children
expects an argument of typeBehavior [Element]
, but everyElement
constructor returns elements wrapped in theUI
monad, so I've ended up with lots of values of the typeBehavior (UI [Element])
.I ended up writing a function to 'bind' such attributes to the UI monad, like so:
Do you think this is a useful helper function, or should the API be extended in some other way?