Re: [heycam/webidl] Differences between "normal" platform objects and "normal" JavaScript classes (#226)

> enumerable (Web IDL) vs. non-enumerable (conventional for ES)

There has been talk of adding something to IDL to control enumerability, so on a technical level we can "solve" this.

The more fundamental problem is the inconsistency in the platform and the lack of a credible plan to bridge it.  :(  ES classes are basically defined to look more like ES builtins here, while IDL standardized de-facto behavior of existing browser builtins like DOM.  The web definitely depends on enumerability for _some_ of the DOM APIs, but I don't know that anyone has a good list of which ones.  Clearly we could make new ones non-enumerable, at the cost of even more confusion, but we could just as easily make new TC39 stuff enumerable, at the cost of even more confusion.  Or maybe neither one is more confusing than what we have now, since most people have no clue which things are ES and which things are IDL-defined anyway.  I don't see any non-sucky outcomes here, honestly...

> statics being functions (Web IDL) vs. methods (conventional for ES)

In the sense that ES statics will examine their "this" object (the constructor object) for some state?

We could quite trivially change this on the IDL side in the sense of passing the "this" object to the spec prose defining the IDL static, which would allow it to use it if it wants.  In practice, there's typically nothing the spec prose wants out of that object, so the distinction is moot in most cases.  In the specific case of URLSearchParams there are no statics to start with, so the distinction is even more moot.  ;)

>  I believe in Gecko at least typeof will also be different.

I'm not aware of anything like this.

> having it clearly documented how "normal" platform objects differ from "normal" JavaScript classes

The most obvious difference is that platform objects have branding checks and JS classes normally don't [1].  JS builtins, which are somewhat like JS clases in some ways and different in others, sometimes do and sometimes don't.

[1] For the same reason they don't normally have interesting toString behavior: you _can_ do it, but it takes some extra effort and most people wouldn't bother.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/226#issuecomment-258873298