extends null

Mark S. Miller erights at google.com
Sat Feb 14 13:26:55 PST 2015


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.



>
> 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 <erights at 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 <axel at 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
> axel at rauschma.de
> rauschma.de
>
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150214/5eef923d/attachment.html>


More information about the es-discuss mailing list