Erik Arvidsson (2015-02-15T18:47:18.000Z)
Making it a dynamic error at class definition time to extend null would
work but the motivation for not doing that was that someone might want to
create a class that has a {__proto__: null} prototype. Personally, I would
be fine with saying that this case is so rare that it would be better to
have that dynamic error at class definition time.

On Sat Feb 14 2015 at 4:52:40 PM Mark S. Miller <erights at google.com> wrote:

> On Sat, Feb 14, 2015 at 1:45 PM, Axel Rauschmayer <axel at rauschma.de>
> wrote:
>
>>
>> On 14 Feb 2015, at 22:26, Mark S. Miller <erights at google.com> wrote:
>>
>> On Sat, Feb 14, 2015 at 1:21 PM, Axel Rauschmayer <axel at rauschma.de>
>> wrote:
>>
>>> But it’s not an error! Either of the following two classes fail later,
>>> when you instantiate them, but not right away.
>>>
>>> ```js
>>> const X = null;
>>> class C extends X {}
>>>
>>> class D extends null {}
>>> ```
>>>
>>
>> I didn't mean to imply an early error. The "extends X" can only produce a
>> dynamic error, so I'm arguing that "extends null" should do the same.
>>
>>
>> When I say “early”, I don’t mean “static”, I mean: dynamically, when the
>> class definition is evaluated, not later when the class is instantiated via
>> `new`.
>>
>> I’m not seeing a dynamic error in the spec when the `extends` clause is
>> null (step 6e):
>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-classdefinitionevaluation
>>
>
>
> That's a good suggestion. AFAICT, it would be an improvement. I don't see
> any downside.
>
> Allen?
>
>
>
>>
>>
>>> Or dynamically switching from "derived" to "base" (but you seem to be
>>> saying that doing this dynamically is not a good idea).
>>>
>>
>> Dynamically switching from derived to base does not work, because our
>> super semantics depends statically on the difference.
>>
>>
>> Ah, checked statically, I wasn’t aware! Hadn’t found the check
>> beforehand. Searched some more and it is indeed there, in 14.5.1.
>>
>> --
>> Dr. Axel Rauschmayer
>> axel at rauschma.de
>> rauschma.de
>>
>>
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>  _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150215/39424687/attachment.html>
d at domenic.me (2015-02-21T00:46:00.050Z)
Making it a dynamic error at class definition time to extend null would
work but the motivation for not doing that was that someone might want to
create a class that has a `{__proto__: null}` prototype. Personally, I would
be fine with saying that this case is so rare that it would be better to
have that dynamic error at class definition time.