4.2.1 states rules about constructors that Proxy doesn't obey

[webbedspace]

https://tc39.github.io/ecma262/#sec-objects

• Each constructor is a function that has a property named "prototype" - Proxy is a constructor but lacks this property.
• Every object created by a constructor has an implicit reference (called the object's prototype) to the value of its constructor's "prototype" property. - exotic proxy objects do not.

This is just an informative section, but I think the "Each" and "Every" in those lines should be watered down.

[ljharb]

Perhaps it would make more sense for Proxy to not require new if it doesn't have .prototype?

[ljharb]

Perhaps it would make more sense for Proxy to not require new if it doesn't have .prototype?

[domenic]

@ljharb I agree, but there was a TC39 meeting where it was decided on requiring new, for vague reasons. It was before my time, but I remember reading the notes and being pretty dissatisfied with the reasoning.

[domenic]

@ljharb I agree, but there was a TC39 meeting where it was decided on requiring new, for vague reasons. It was before my time, but I remember reading the notes and being pretty dissatisfied with the reasoning.

[ljharb]

Then on the flip side - perhaps Proxy should have a .prototype object, even if the resulting instance doesn't use it (which is totally doable in ES3 even)?

[ljharb]

Then on the flip side - perhaps Proxy should have a .prototype object, even if the resulting instance doesn't use it (which is totally doable in ES3 even)?

[allenwb]

4.2 is summary of the language that dates to ES1 (thanks, rpg). As it states, 4.2 is a non-normative overview of the language. It's ok of it to fuzz some details in order to simplify the conceptual overview.

But, it's easy enough to make the language in question more precise:

• Each constructor is a function that typically has a property named "prototype".
• Every object created by a constructor has an implicit reference (called the object's prototype) that typically is set to the value of its constructor's "prototype" property.

However, it isn't clear to me that adding "typically" actually improves the over view very much. And I'm sure this isn't the only nit that could be picked from 4.2. If such nits are too objectionable, an alternative would be to completely eliminate section 4.2.

( note the second point is still only conceptual view and not 100% accurate. More precisely, every object has an internal method [[GetPrototypeOf]] ...)

[allenwb]

4.2 is summary of the language that dates to ES1 (thanks, rpg). As it states, 4.2 is a non-normative overview of the language. It's ok of it to fuzz some details in order to simplify the conceptual overview.

But, it's easy enough to make the language in question more precise:

• Each constructor is a function that typically has a property named "prototype".
• Every object created by a constructor has an implicit reference (called the object's prototype) that typically is set to the value of its constructor's "prototype" property.

However, it isn't clear to me that adding "typically" actually improves the over view very much. And I'm sure this isn't the only nit that could be picked from 4.2. If such nits are too objectionable, an alternative would be to completely eliminate section 4.2.

( note the second point is still only conceptual view and not 100% accurate. More precisely, every object has an internal method [[GetPrototypeOf]] ...)

[allenwb]

More generally... a constructor is an object that has a [[Construct]] internal method. It isn't the case that all constructors are required to have a prototype property. That is only a requirement of some concrete [[Construct]] internal methods.

[allenwb]

More generally... a constructor is an object that has a [[Construct]] internal method. It isn't the case that all constructors are required to have a prototype property. That is only a requirement of some concrete [[Construct]] internal methods.

[ljharb]

Other than Proxy, is there anything else that does not have a 1:1 relationship with [[Construct]] and .prototype?

[ljharb]

Other than Proxy, is there anything else that does not have a 1:1 relationship with [[Construct]] and .prototype?

[erights]

Other than Proxy, is there anything else that does not have a 1:1 relationship with [[Construct]] and .prototype?

const sillyCounterExample = () => {};
sillyCounterExample.prototype = 7;

[erights]

Other than Proxy, is there anything else that does not have a 1:1 relationship with [[Construct]] and .prototype?

const sillyCounterExample = () => {};
sillyCounterExample.prototype = 7;

[ljharb]

@erights yes but arrow functions can't be constructed

[ljharb]

@erights yes but arrow functions can't be constructed

[webbedspace]

Then on the flip side - perhaps Proxy should have a .prototype object, even if the resulting instance doesn't use it (which is totally doable in ES3 even)?

This is a different topic, but I recently noticed the peculiarity in Proxy having [[Construct]] but no prototype allows this to occur:

class B extends Proxy {} // Error
Proxy.prototype = {}
class C extends Proxy {} // Okey-dokey
new C({}, { get() { return 8 }}) // No semantic difference from the actual Proxy constructor, though.

I was thinking that perhaps it could have a prototype property with value: undefined, writable: false, configurable: false, enumerable: false to elide this (and to restore the invariant that constructors have non-configurable non-writable prototypes).

[webbedspace]

Then on the flip side - perhaps Proxy should have a .prototype object, even if the resulting instance doesn't use it (which is totally doable in ES3 even)?

This is a different topic, but I recently noticed the peculiarity in Proxy having [[Construct]] but no prototype allows this to occur:

class B extends Proxy {} // Error
Proxy.prototype = {}
class C extends Proxy {} // Okey-dokey
new C({}, { get() { return 8 }}) // No semantic difference from the actual Proxy constructor, though.

I was thinking that perhaps it could have a prototype property with value: undefined, writable: false, configurable: false, enumerable: false to elide this (and to restore the invariant that constructors have non-configurable non-writable prototypes).

[allenwb]

Note that the default [[Construct]] internal method of ECMAScript function objects does not require that the constructor function have a prototype property.
@erights
bound functions may be constructable but do not have a prototype property
implementation defined exotic functions may be constructors but need not have a prototype property.

I don't see any need for any normative changes relating to the prototype of constructors. The spec. reflects reality as it has existed since the early days of ES.

[allenwb]

Note that the default [[Construct]] internal method of ECMAScript function objects does not require that the constructor function have a prototype property.
@erights
bound functions may be constructable but do not have a prototype property
implementation defined exotic functions may be constructors but need not have a prototype property.

I don't see any need for any normative changes relating to the prototype of constructors. The spec. reflects reality as it has existed since the early days of ES.

[erights]

@allenwb That seems right to me.

[erights]

@allenwb That seems right to me.

[bterlson]

I think 4.2 (and all of Clause 4) is a useful overview to have. But @allenwb is right, there are other nits there. Proxies especially would require lots of "typically's" to be added in various places. One possible way to avoid that is to define terms in a spec-rigorous way (Eg. a constructor is an object with a [[Construct]] slot) but that erodes much of the value of this high-level non-normative description. I think this is fine to leave as-is.

[bterlson]

I think 4.2 (and all of Clause 4) is a useful overview to have. But @allenwb is right, there are other nits there. Proxies especially would require lots of "typically's" to be added in various places. One possible way to avoid that is to define terms in a spec-rigorous way (Eg. a constructor is an object with a [[Construct]] slot) but that erodes much of the value of this high-level non-normative description. I think this is fine to leave as-is.