classes and enumerability
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
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
> ... 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.
More information about the es-discuss