- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 26 Jun 2013 16:00:20 +0100
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-script-coord@w3.org
On Wednesday, June 26, 2013 at 3:43 PM, Boris Zbarsky wrote:
> On 6/26/13 10:39 AM, Marcos Caceres wrote:
> > Yes, the developer needs to be able to monitor changes to the array.
>
> As in get notified when it changes? Or as in always see whatever the
> state is now as opposed to what it was then?
Yes, get notified when it changes. There are other events that describe what actually happened (e.g., a call was added or a call was disconnected and hence removed from the array). You can already see the multiple levels of suckness here - all this could be encapsulated by Object.observe - yes, I see that you say below it can't be used; just saying' :(
> Again, this is "just" (I put it in quotes, because it's actually really
> important) an API design issue.
Sorry, I didn't take this up properly last time. I'm uncertain about what the right idiomatic design pattern is to use, which was also a reason I reached out to the list for guidance.
>
> > Small question: there is an event defined for monitoring changes to the Calls array in the API ("callschanged" and corresponding "oncallschanged" event handler attribute) which I think kinda sucks (hence my previous email asking about using Object.observe) - I wanted to get rid of the event. Is there some way of monitoring this array without an event?
>
>
> There is not, no.
>
> > Object.observe(telephony.calls, function(details){...}) feels really right here.
>
> You can't have that for a readonly array, sadly, because it would
> involve the UA being able to change the properties as own value
> properties, which would mean the page can do it too...
Ah, bah :( Events it is then.
Thanks again!
Received on Wednesday, 26 June 2013 15:00:50 UTC