W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2015

Re: [sensors] Dependency on [DOM] due to inheriting from EventTarget

From: Jafar Husain via GitHub <sysbot+gh@w3.org>
Date: Tue, 02 Jun 2015 19:13:10 +0000
To: public-device-apis@w3.org
Message-ID: <issue_comment.created-108062140-1433272389-sysbot+gh@w3.org>
@rwaldron the type of values would be whatever was in sensor 1 until 
the condition was met and then sensor 2. Let's say accelerometer 
positions for example. The example is just to demonstrate that 
declarative composition is possible if the underlying type supports a 
completion semantic.  I'd love to put together a real use case and 
will do so when I get a chance. Suggestions of thorny signal 
composition problems are welcome.

If all you are doing is listening to a single sensor for the life of a
 program and taking no action beyond updating a variable, composition 
won't be very interesting to you. My suspicion is that there are many 
use cases for combining sensors into new more complex sensor streams. 

Remove event listener is insufficient to describe concatenation. Let 
me try and do a better job of explaining. An Observable emits a 
special completion signal (like generator) when it's finished. 

sensor.subscribe({ next(v) { /* got a sensor value */ }, return(v) { 
/* got a completion signal */ });

A completion signal might _seem_ unnecessary for a sensor, which is 
presumably an infinite stream. However it is interesting to note that 
you can compose infinite streams together with functions and other 
streams to create _finite_ streams. That is what this subexpression 
does:

sensor1.takeWhile(pos => pos.x - pos.y)

This creates an observable which ends when the condition is met. 
Observables also free subscriptions when they end, so  there is no  
need to call remove event listener. Because the Observable type  has a
 clear end signal, you can build more interesting combinators  like 
concatenation:

sensor1.takeWhile(pos => pos.x - pos.y).concat(sensor2)

The concatenation method looks for the return method to be called, and
 then begins listening to the other sensor. Without an explicit 
completion semantic in EventTarget, building either of these methods 
isn't possible. We'd have to add more semantics to EventTarget to make
 that happen.

-- 
GitHub Notif of comment by jhusain
See https://github.com/w3c/sensors/issues/21#issuecomment-108062140
Received on Tuesday, 2 June 2015 19:13:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC