- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 19 Aug 2014 08:01:07 -0700
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Jonas Sicking <jonas@sicking.cc>, Marcos Caceres <w3c@marcosc.com>
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote: >> Note that in the API that I'm proposing, there is no way to >> accidentally rely on GC behavior. If a WakeLock object is GCed before >> it has been release()ed, then the lock is held indefinitely (until the >> user leaves the page of course). >> >> I.e. an unbalanced request() and release() in both the currently >> proposed API, and in the API that I propose behave the same, the lock >> is held indefinitely. Any objects getting GCed does not change this. > > I overlooked that aspect, my apologies. It sounds good. I am not sure if > that would be safer than global methods in the sense that developers > will still be able to shoot themselves in the foot by not calling > .release() or might assume that .release() will be called upon object > destruction. > > How would you handle feature detection with this design? Assuming there are multiple types of wakelock classes, you just test for their existence. ~TJ
Received on Tuesday, 19 August 2014 15:01:55 UTC