classes and enumerability

Boris Zbarsky bzbarsky at mit.edu
Fri Jan 30 05:20:41 PST 2015


On 1/30/15 1:44 AM, Andrea Giammarchi wrote:
> Developers have to understand they cannot `new HTMLDivElement()` anyway

That will change.

> I am not sure why you see this misalignment that has always been there a
> problem just now

I've seen it as a problem for a while now, as a cursory look at mailing 
list archives will tell you.

> but also I am not sure I understand why this wouldn't
> be equivalent:

Do you also not understand why ES6 needed to grow enough primitives to 
explain "host objects" and so forth?

Basically, the fact that we have two somewhat but not quite different 
things going on is going to be confusing to people, so if we can align 
them we should.

> You have already properties and types nobody can set or ensure in native
> JS

You can implement the equivalent in native JS nowadays (except for 
document.all).  That's been the point of a lot of the recent evolution 
of JS.  And while the integration between the two is not perfect yet, 
once of the goals of the ES6 class work has been to improve said 
integration.

> ... and I would never stop a programming language from evolving
> because "another one" (that' how I see WebIDL) is limited or
> historically different ... I mean, it is different, it has always been,
> why is this a concern only today?

_THIS_ is one of the big problems I see with how the web platform is 
developed.  Some people view it as multiple independent fiefs to be 
developed independently, as opposed to a single coherent platform.

> Genuinely curious, but non enumerable for JS classes is **good** and I
> believe it should not be re-changed.

Did I suggest it should be re-changed?  Did you even read anything I 
wrote in this thread?  Please go and do so.

-Boris



More information about the es-discuss mailing list