Re: [whatwg] Feature-detectable WakeLocks

>> 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.

Really?

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:
Element.firstChild.getAttribute(…);
Element.nextSibling.getAttribute(…);
 
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