On Sat, Feb 14, 2015 at 1:21 PM, Axel Rauschmayer <a...@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.
>
> I’m arguing that both produce weird constructors. I’d much prefer an early
> error.
>
You can't know early that X is null.
> 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.
>
>
> On 14 Feb 2015, at 22:05, Mark S. Miller <erig...@google.com> wrote:
>
> No, the problem is that
>
> class C extends X {
>
> when X turns out to be null must be an error along exactly these lines.
> Everywhere else in the language where X is accepted as an expression
> evaluated to a value, if X evaluates to null, this is the same thing as
> placing null in that position. Consider:
>
>
> const NULL = null; // C nostalgia
>
> class C extends NULL {
>
>
> It would be awful for this to be different than
>
> class C extends null {
>
>
> If you really want to write a class whose prototype.__proto__ is null,
> imperatively make it so after the class declaration. We don't need to
> compromise the consistency of the language to make this rare case less ugly.
>
>
>
>
> On Sat, Feb 14, 2015 at 12:52 PM, Axel Rauschmayer <a...@rauschma.de>
> wrote:
>
>> If I’m reading the latest spec draft correctly then
>>
>> ```js
>> class C extends null {
>> }
>> ```
>>
>> produces the following result:
>>
>> 1. Constructor kind: derived
>> 2. Prototype of `C`: `Function.prototype`
>> 3. Prototype of `C.prototype`: `null`
>>
>> Neither #2 nor #3 seems very useful:
>>
>> * #2 means that a super-constructor call is allowed but throws an
>> exception, because `Function.prototype` is not constructible. The default
>> constructor will perform a super-constructor call. As a result, you are
>> forced to explicitly return an object from the constructor if you don’t
>> want an exception to be thrown.
>>
>> * #3 means that the constructor doesn’t even create objects whose
>> prototype is `null`, but objects whose prototype is an object whose
>> prototype is `null`.
>>
>> Therefore my question: is this useful for anything? Can’t `extends null`
>> be turned into something useful? Even treating `extends null` as equivalent
>> to a missing `extends` clause seems preferable.
>>
>> Thanks!
>>
>> Axel
>>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
