- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 19 Aug 2014 13:38:43 -0700
- To: Marcos Caceres <w3c@marcosc.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Mounir Lamouri <mounir@lamouri.fr>, Jonas Sicking <jonas@sicking.cc>
On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres <w3c@marcosc.com> wrote:
> On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jonas@sicking.cc) wrote:
>> > > How would you handle feature detection with this design?
>>
>> This is a good question. I don't have a better solution than adding
>> separate DisplayWakeLock() and SystemWakeLock() classes.
>>
>
> Might make sense to do it this way regardless. It might be that we need to add different behavior for each type of lock in the future.
>
> Ok, so taking into consideration the feedback received so far - how about something like:
>
> ```
> [Constructor]
> interface DisplayLock : WakeLock {
> static readonly attribute boolean isHeld;
> }
>
> [Constructor]
> interface SystemLock : WakeLock {
> static readonly attribute boolean isHeld;
> }
Why is isHeld still used here? You don't need it to avoid squashing
someone else's lock with this design, and several people have pointed
out that exposing it is a footgun, as people might check it and decide
they don't need to request their own lock (only to be screwed when the
other lock releases earlier or later than they expected).
~TJ
Received on Tuesday, 19 August 2014 20:39:28 UTC