A new hack for singleton objects

I would like to get opinions from others on public-script-coord on this new "hack" I/Mounir thought up, for getting "singleton objects" of a sort while staying within the confines of WebIDL.

### Problem statement

Many things on the platform are singletons. Examples: navigator.geolocation, navigator.battery, most things on navigator, window.history, many things on window. Idiomatic ES2015 would probably express these as modules. Idiomatic ES5 would likely express these as simply objects, IMO.

All APIs today seem to express these as single instances of non-constructible classes, e.g. window.history is an instance of window.History, which cannot be constructed except by the UA. This is pretty weird (IMO), as classes should be for things you plan to create multiple instances of, using its (working) constructor. In JS singleton classes are fairly silly; if you're only going to have one frobber in your project, just do `var frobber = { frob() { ... } }` instead of creating a whole `Frobber` class, guarding it so that the first time it's constructed it poisons itself against all future construction, and then saying `var frobber = new Frobber()`.

### Solution??

The current design of the permissions API somewhat sidesteps this by making a `window.Permissions` interface which only has static methods and is non-constructible. This ends up behaving ... a lot like an object, or even module. It's non-callable, non-constructible, and has data properties which are functions. The only differences I see are: (a) it looks function-ey instead of object-ey, e.g. via `typeof` or `.constructor` or `instanceof` or `__proto__` (b) the capitalization implies to people that Permissions is a class, instances of which should either exist or be constructible. (For (b), the reasoning is: when I see `window.Text`, that is a hint that I will probably be able to create instances of `Text`. When I see `window.HTMLUnknownElement`, that is a hint that instances of `HTMLUnknownElement` will be created at least by the browser, if not by me.)

Of course, (b) could even be sidestepped by renaming the "interface" to be lowercase. This would give a `window.permissions` which is ... closer to idiomatic ES5 than `window.history` is, by my judgement.

What do people think? Too crazy, or just crazy enough? (Or, not crazy enough, i.e., we should just add namespace objects to WebIDL and get on with it? But nobody wants to block shipping new APIs on that, better to just wait until modules arrive I guess...)

Received on Tuesday, 17 March 2015 11:29:44 UTC