- From: zenparsing via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Jun 2015 03:46:26 +0000
- To: public-device-apis@w3.org
> honestly, I'd rather see Sensor wait for EventEmitter than continue down the path with EventTarget and all of the baggage it entails. I find this a little odd since, from my point of view, EventEmitter and EventTarget are equally terrible user-facing APIs, in that neither one allow for composition and abstraction. For instance, if you are modeling a push stream and using Observable, then "once" doesn't need to be implemented at the API level; it can instead be implemented as a standard combinator over all observables: (Taking some liberty with the proposed `::` operator.) ```js function first() { return new Observable(sink => { let subscription = this.subscribe({ next(v) { sink.next(v); // Stop listening after we've received one event subscription.unsubscribe(); }, throw(v) { sink.throw(v) }, return() { sink.return() }, }); }); } sensor.observe("change")::first().forEach(x => { // do whatever, but only once }); ``` I'm not saying the Sensor API should necessarily be implemented using observables, but I think we should be looking forward to compositional solutions like Observables and AsyncIterators rather than old-school event dispatch APIs like EventTarget and EventEmitter. -- GitHub Notif of comment by zenparsing See https://github.com/w3c/sensors/issues/21#issuecomment-111343884
Received on Friday, 12 June 2015 03:46:31 UTC