W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] Feature-detectable WakeLocks

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 19 Aug 2014 04:07:43 +0100
Message-Id: <9738E408-67AF-4A84-B28D-186379586831@geekhood.net>
To: Marcos Caceres <w3c@marcosc.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>

>> I'd prefer if individual lock types were instances of objects, e.g. navigator.*Lock objects could be instances of a variant of the WakeLock interface:
>> navigator.screenLock.request();
>> navigator.screenLock.isHeld();
>> navigator.cpuLock.request();
>> navigator.cpuLock.release();
> Personally, this doesn't strike me as good API design. It means having a bunch of attributes that all use the same class but only differ in name.


I think clearly separating different classes of locks (with a common base class) is much better than conflating them behind a weakly typed string-driven API.

It's like:
instead of:
Element.getAttribute("firstChild", …);
Element.getAttribute("nextSibling", …);

>> Alternatively, if the WakeLock was instantiable (to have a standard way for independent page components to share locks) then these objects could be constructors:
>> if (navigator.ScreenLock) {
>> var lock = new navigator.ScreenLock();
>> …
>> lock.release();
>> }
>> (or `new navigator.wakeLocks.Screen()`, etc.)
> We don't have any APIs like this today on the Web.  It would be weird :)  

"Weird" is subjective and a vague criticism. Can you elaborate what's wrong with that?

> It would just be better to have a constructor on the interface: `new WakeLock("screen")` or whatever.  

I don't see any benefit in obscuring types of the objects. 

String-driven API doesn't allow simple feature detection, and a single type that conflates all lock types makes extensibility uglier. You won't be able to elegantly add methods that are valid only for some types of locks, e.g. `new WakeLock("cpu").dimScreen()` is nonsense, but would valid from perspective of WebIDL and JS prototypes.

regards, Kornel
Received on Tuesday, 19 August 2014 03:08:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC