- 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