Null only as default prototype

[ghost]

Is null the only prototype that these objects may have?

What would be the result of this code?

const frozen = {#
    __proto__: Map.prototype,
    x: 1.5,
    y: 4.5
#};

Reflect.getPrototypeOf(frozen); // Map.prototype or null?
"has" in frozen; // true or false?

I think that these should be Map.prototype and true appropriately, and that null should merely be the default prototype, if left unspecified.

Would these semantics make any sense in the eyes of TC39? Could this be considered to be a part of the proposal?

[keithamus]

Could you please describe how this would be practical in real world code? I can't think of a useful case where I'd want a frozen object that has a prototype using this syntax.

[ghost]

Could you please describe how this would be practical in real world code? I can't think of a useful case where I'd want a frozen object that has a prototype using this syntax.

Well, maybe a code base is quite used to having objects that inherit from Object.prototype. Most JavaScript in the wild does, and any code that uses third-party libraries definitely would need to maintain the Object.prototype methods on passed objects.

[keithamus]

Could you please describe how this would be practical in real world code? I can't think of a useful case where I'd want a frozen object that has a prototype using this syntax.

Well, maybe a code base is quite used to having objects that inherit from Object.prototype. Most JavaScript in the wild does, and any code that uses third-party libraries definitely would need to maintain the Object.prototype methods on passed objects.

IIRC the only method in Object.prototype is hasOwnProperty, for which there is a proposal to move this to the Object namespace: https://github.com/tc39/proposal-accessible-object-hasownproperty

Due to these factors I'm not sure this is a completely compelling reason.

[theScottyJam]

There's a number of methods on the Object prototype (see here), such as .toString(), propertyIsEnumerable(), etc. Many of them are deprecated, and all of the others should not get used in practice (because you should always be prepared to receive an object that may be shadowing the inherited methods, or that's using a null prototype), but people out there do use the inherited methods anyways.

With that said, any library that's calling methods directly, such as an object's .toString() method needs to stop doing that, as that code won't work in a number of scenarios. Userland code that's setting an object's prototype to Object.prototype is just fixing some immediate symptoms, not the underlying issue.