Kulla API changes: shifting to events

[Robert Field]

I keep trying to steer away from complexity.  For our needs unicast is 
enough, actually better since it is simpler.
Would it be a reasonably approach to provide unicast and for those that 
need it they can add their own multiplexing on top?

Another perspective is that, for our current tool/testing needs, there 
is no need to unsubscribe, so never dealing with tokens, letting them 
fall on the ground, is fine.

-Robert



On 06/01/15 08:57, Brian Goetz wrote:
>> It will have event registration and at least initially and probably
>> permanently a List of events would be returned by eval() -- presumably
>> with value/exception -- and by drop().
>
> There are a few degrees of freedom in event/listener management.
>
>  - Are events unicast or multicast?  (i.e., what does it mean if you 
> call onEvent(Consumer<Event>) twice?  does the second call replace the 
> first, or do both listeners get the event?)
>  - If events are multicast (the most common interpretation), how do 
> you unsubscribe?
>  - How fine-grained are event subscriptions?
>
> You've talked about leaving room for a "plugin" mechanism in the 
> future.  Presumably the plugin would be provided access to the REPL 
> state.  And then it might want to attach its own listeners.
>
> The historical view of listener support (from the Beans days) relies 
> on the identity of the listener; if you pass a listener to 
> unsubscribe(), it is removed from the list.  But, this is not a very 
> lambda-friendly mechanism, as you can't count on the identity of a 
> lambda.  So a more lambda-friendly API might be:
>
>     SubscriptionToken subscribe(listener)
>     void unsubscribe(subscriptionToken)
>