RE: A new hack for singleton objects

From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 

> We could change this in Web IDL, right?  As in, we could have interfaces that only have static attributes/operations and have nothing inheriting from them have no [[Call]] or [[Construct]] and have Object.prototype on their proto chain.  And no .prototype (which is already the case for CSS, say, in Gecko, which is currently technically a spec violation).

Sure. Any reason not to just make them objects?

> Nothing actually prevents you from writing "interface permissions" in your IDL, as you noted.
>
> But also, there is precedent for capitalized non-class things with typeof == "object" in the platform (Math comes to mind).  I guess it depends on whether you're thinking of your thing as an object or a collection of functions.

Yeah, combined with the CSS and (old) URL examples, I'm convinced that there's enough precedent that capital-P Permissions is more consistent. Not to mention ES2015 Reflect. My bad.

> The distinction between objects and namespaces may be somewhat important when you try to apply methods cross-global.
>
> If you do something like:
>
>   window.history.back.call(otherWindow.history)
>
> that will navigate otherWindow today, because the History methods operate on their "this" object and that object is associated with otherWindow.
>
> But current static methods in Web IDL don't have a concept of "this object" at all, afaict.  So if you do:
>
>   window.Notification.requestPermission.call(otherWindow.Notification)
>
> that will request permissions in the context of window (which is the global of the Realm of the requestPermission function), and completely ignore the "this" value.

Hmm. Well, modules are allowed to have state too. Maybe that is just sloppy though and we shouldn't use it for web platform modules? I could see that argument.

There is *some* sort of dependency in Notification.requestPermission() or Permissions.query() on the global---they need at the very least to find out the origin in which to run. I'd imagine that they don't use the `this` value, but they do use the global in which they were defined. If you translate that into modules, it's the same as writing

    export function query() {
      return queryPermissionsFor(getOriginFor(window));
    }

I guess I am trying to tease apart whether `window.history` *should* be different from `Permissions.query()`. Or should `history.back()` just be a function that happens to operate on the window its definition captures. Of course, as you note, currently, `history.back` is very much a method currently. But I'm just wondering whether we can come up with a clear guideline going forward as to which pattern is preferred in which situation.

>> But nobody wants to block shipping new APIs on that, better to just 
>> wait until modules arrive I guess...)
>
> I don't quite follow how waiting for a different thing makes things better in terms of not blocking APIs.  ;)

Yeah, poorly phrased, I meant, no need to solve this conundrum now, might as well just wait for modules and stick with what we've got in the meantime.

Received on Wednesday, 18 March 2015 13:05:10 UTC