Re: A new hack for singleton objects

On 3/18/15 9:04 AM, Domenic Denicola wrote:
>> 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?

Not offhand.  The only worry I can see is that if you add something 
non-static suddenly it becomes a function.  But I don't think that's a 
problem.

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

As currently defined, Notification.requestPermission uses the origin of 
"wherever script was entered" (entry settings object's origin).  See 
<https://notifications.spec.whatwg.org/#dom-notification-requestpermission>. 
  I personally consider this sort of action-at-a-distance very broken, 
but some spec editors seem to think that because UAs do it for some 
things (e.g. Location) we should do it for everything.  :(

I can't find a spec for Permissions.

> If you translate that into modules, it's the same as writing
>
>      export function query() {
>        return queryPermissionsFor(getOriginFor(window));
>      }

Modulo non-current-inner issues...

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

It really depends on whether you want to support grabbing the function 
once and then applying it to different history objects or not, right?

-Boris

Received on Wednesday, 18 March 2015 13:12:02 UTC