Kulla API changes: shifting to events

[Brian Goetz]

I'm generally in favor of starting simple and working up as well -- as 
long as it can be scaled up. On the other hand, I worry about setting 
out roadblocks that will, for example, make a plugin approach impractical.

I think the token approach is a good compromise on that ground; as you 
say, simple clients can let them fall on the floor.

Multicast is not really that complex to implement; instead of:

   Consumer listener;
   ...
   if (listener != null)
       listener.accept(event)

we would have

   List<Consumer> listeners;
   listeners.forEach(l -> l.accept(event));

(actually both cases probably want a try .. catch around the accept 
invocation, to protect against listeners that throw NPEs and such.)


A more interesting question is how to divide up the event space.  IIRC, 
there are currently two kinds of events:
  - entity state transition events
  - remote process termination events

There are lots of kinds of entities and transitions; is one bucket for 
these enough (probably).  But its worth brainstorming over what other 
events might be added in the future, just to ensure we have a scalable 
API idiom.







On 6/1/2015 12:10 PM, Robert Field wrote:
> 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)
>>
>