- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 15 May 2013 15:18:29 -0700
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, May 15, 2013 at 6:44 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > On 09/05/13 21:42, Christophe Dumez - SISA wrote: >> Hi, >> >> I commented on that bug. If I remember correctly, clear() was added for consistency with the Contact API. >> It is merely a convenience function so I don't have strong feeling either way. >> >> However, I do think that clear() is a lot more readable than getPendingAlarms().then(alarms=>alarms.forEach(x=>x.cancel())); > > .clear() has a performance advantage compared to > .getPendingAlarms().then(alarms=>alarms.forEach(x=>x.cancel())): when > you use .clear() there will be only one DB access that will remove every > alarm that belongs to the caller. Using .cancel() for each alarm might > do as much calls to the DB which is going to be significantly slower. It > is possible to argue that a clever implementation could delay the DB > access so it can perform multiple operations at the same time but I > think having a .clear() method is a syntax sugar that could make life > easier for developers and implementations and it is worth taking. How common is it for applications to need to cancel all alarms though? I can't think of any use cases other than "complete system reset", which I don't think is a common UI to expose to users from within an app. The only reason that I think we ended up with .clear() in the contacts API (which as I understand it this was copied from) was that it was useful during testing and development of the API itself. Hardly something we should optimize for. / Jonas
Received on Wednesday, 15 May 2013 22:19:26 UTC