Yehuda Katz (2015-01-29T21:54:28.000Z)
Yehuda Katz
(ph) 718.877.1325

On Thu, Jan 29, 2015 at 1:46 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 1/29/15 4:36 PM, Yehuda Katz wrote:
>
>> Are you asking what to do about the fact that existing WebIDL "classes"
>> produce enumerable properties that probably can't be made non-enumerable
>> without breaking the web?
>>
>
> I think the following things need to be decided:
>
> 1)  What should the behavior be for WebIDL objects going forward?
> 2)  If the going forward behavior is to have properties non-enumerable,
>     should we try to migrate some subset of the existing Web IDL
>     objects to the new behavior?
>
> I'm pretty sure we can't migrate all existing things, at least without
> breaking someone somewhere, but I suspect we can migrate many of them, if
> we decide it's actually worthwhile.
>

To be completely clear, there's nothing that requires DOM to define its
objects as using precisely the semantics of ES6 "classes", and indeed,
nothing that stops an ES6 class from having enumerable methods:

class Simple {
}

// enumerable

Simple.prototype.method = function() {}

If I understand you correctly, what you're saying is that you would *like* DOM
"classes" to look similar to a normally defined ES6 class.

That is a reasonable desire (and I would love to continue discussing it),
but it's not something that's squarely in TC39's wheelhouse (since DOM
classes aren't defined using ECMAScript class syntax, which is all that
this decision directly affects).


>
> I'd be pretty interested in knowing what other implemntors think here,
> because if we make some decision on #1 I'd rather not have people continue
> to ship whatever they do now instead of what we decided on. We've been
> having a _lot_ of that happen with Web IDL.  :(
>
> -Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150129/56990711/attachment.html>
d at domenic.me (2015-02-13T23:35:13.057Z)
To be completely clear, there's nothing that requires DOM to define its
objects as using precisely the semantics of ES6 "classes", and indeed,
nothing that stops an ES6 class from having enumerable methods:

```js
class Simple {
}

// enumerable

Simple.prototype.method = function() {}
```

If I understand you correctly, what you're saying is that you would *like* DOM
"classes" to look similar to a normally defined ES6 class.

That is a reasonable desire (and I would love to continue discussing it),
but it's not something that's squarely in TC39's wheelhouse (since DOM
classes aren't defined using ECMAScript class syntax, which is all that
this decision directly affects).