You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's a term used in multiple places in the specification, and it'd be great for it to link to that it is (i.e. internal methods that are guaranteed to be on all objects).
The actual semantics of objects, in ECMAScript, are specified via algorithms called internal methods. Each object in an ECMAScript engine is associated with a set of internal methods that defines its runtime behaviour. [...]
[...]
Table 4 summarizes the essential internal methods used by this specification that are applicable to all objects created or manipulated by ECMAScript code. Every object must have algorithms for all of the essential internal methods. However, all objects do not necessarily use the same algorithms for those methods.
[...]
Table 5 summarizes additional essential internal methods that are supported by objects that may be called as functions.
[...]
So:
we do not have any example in our spec of an internal method that is not an essential internal method
not all essential internal methods are defined on all objects, because of [[Call]]/[[Construct]]
I suggest that we just unify the two concepts, and just call them "internal methods". If we want to keep them separate, probably [[Call]] and [[Construct]] should not be considered to be essential.
Actually, is there any difference between "internal methods" and "essential internal methods"?
You'd probably have to ask @allenwb, but my guess is that the difference allows a host to define an exotic object with non-essential internal methods. Of course, the ES semantics only invoke the essential ones, so such a host would need some non-standard mechanism to invoke the non-essential ones.
But I'm doubtful that the the ES spec needs to allow for the existence of non-essential internal methods.
my guess is that the difference allows a host to define an exotic object with non-essential internal methods.
Yes that. Prior to ES6 there was lots of confusion about where were the essential characteristics of the ES object model.
But I'm doubtful that the the ES spec needs to allow for the existence of non-essential internal methods.
I think for a while we considered using the term "standard internal method" instead of "essential internal method" but then the exotic object methods standardized in 10.4 would colloquially be "non-standard methods" which seemed like a misnomer.
I think that collectively sections 6.1.7 and 10 do a pretty good job of introducing the spec's object model. It may not be ontologically perfect but I don't seen a lot of value to be gained from further tweaking of it. Not to mention the possible impact on people who have already internalized it.
I think for a while we considered using the term "standard internal method" instead of "essential internal method" but then the exotic object methods standardized in 10.4 would colloquially be "non-standard methods" which seemed like a misnomer.
Does this mean that "essential internal methods" refers specifically to the non-exotic behavior? So the object model is basically an interface that objects must implement by providing implementations for the internal methods, and one specific instance of those implementations is the "essential" one?
The essential internal method interfaces (defined in Table 4 and 5) are essential because they are used to define the runtime semantics of the Object Type manipulating syntactic language features (and built-in library). Section 10.1-10.3 defines the the ordinary (i.e. default) implementation of the the essential internal method interfaces. Section 10.4-10.5 defines other exotic implementations of those interfaces that are used for various objects in the built-in library.
ECMAScript implementations and hosts (e.g. web browsers) might defines other exotic implementations of the essential internal method interfaces but those are outside of the prevue of ECMA-262.
Stepping back a ways, the essential internal method interfaces are the Metaobject protocol of the ECMAScript language.
We discussed this in the editor call, and we're leaning towards keeping both concepts ("essential internal method" and "internal method"), but marking [[Call]] and [[Construct]] as not essential since they are not guranteed to exist on all objects.
Something I haven't seen mentioned is that the name "essential internal methods" is acts a link to the requirements specified in 6.1.7.3 Invariants of the Essential Internal Methods. Some of those requirements apply to [[Call]] and [[Construct]]. So if [[Call]] and [[Construct]] are not essential internal methods then it is also going to require some changes to that section.
I think a simpler clarification of the original issue could be achieved as follows.
In section 6.1.7.2 modify the following paragraph as shown below:
Table 4 summarizes the essential internal methods used by this specification that are applicable to all objects created or manipulated by ECMAScript code. Every such object must have algorithms for all of the those essential internal methods. However, all objects do not necessarily use the same algorithms for those methods.
Move the paragraph that is currently between Table 4 and Table 5 so it immediately follows the above paragraph and make the modifications shown here:
Table 5 summarizes two additional essential internal methods that are supported by applicable to objects that may be called as functions. A function object is an object that supports has an algorithm for the [[Call]] internal method. A constructor is an object that supportshas an algorithm for the [[Construct]] internal method. Every object that supports [[Construct]] must support [[Call]]; that is, every constructor must be a function object. Therefore, a constructor may also be referred to as a constructor function or constructorfunction object.
It might also make sense to move the final (after Table 5) paragraph of 6.1.7.2 so that it comes after the paragraph that begins:
some of those have some invariants that need to be respected by all objects that implement them
some of those are applicable to all objects created or manipulated by ECMAScript code
Right now, the spec calls:
internal methods what is described in (1)
essential internal methods things that are either (2) or (3)
I would like to disambiguate the spec on whether essential internal methods are (2) or (3). Your proposed change clarifies that essential internal methods is (2), which is fine for me. I'll open a PR with it.
Yesterday in the editor call we couldn't come up with an example of something that is in (1) but not in (2), so it wasn't clear that we even need that distinction. However, it seems like the streams spec does define some extra internal methods (https://streams.spec.whatwg.org/#rs-default-controller-internal-methods).
Activity
nicolo-ribaudo commentedon Jul 20, 2026
Actually, is there any difference between "internal methods" and "essential internal methods"? https://tc39.es/ecma262/#sec-object-internal-methods-and-internal-slots says:
So:
I suggest that we just unify the two concepts, and just call them "internal methods". If we want to keep them separate, probably [[Call]] and [[Construct]] should not be considered to be essential.
jmdyck commentedon Jul 21, 2026
You'd probably have to ask @allenwb, but my guess is that the difference allows a host to define an exotic object with non-essential internal methods. Of course, the ES semantics only invoke the essential ones, so such a host would need some non-standard mechanism to invoke the non-essential ones.
But I'm doubtful that the the ES spec needs to allow for the existence of non-essential internal methods.
allenwb commentedon Jul 21, 2026
Yes that. Prior to ES6 there was lots of confusion about where were the essential characteristics of the ES object model.
I think for a while we considered using the term "standard internal method" instead of "essential internal method" but then the exotic object methods standardized in 10.4 would colloquially be "non-standard methods" which seemed like a misnomer.
I think that collectively sections 6.1.7 and 10 do a pretty good job of introducing the spec's object model. It may not be ontologically perfect but I don't seen a lot of value to be gained from further tweaking of it. Not to mention the possible impact on people who have already internalized it.
nicolo-ribaudo commentedon Jul 22, 2026
Does this mean that "essential internal methods" refers specifically to the non-exotic behavior? So the object model is basically an interface that objects must implement by providing implementations for the internal methods, and one specific instance of those implementations is the "essential" one?
allenwb commentedon Jul 22, 2026
@nicolo-ribaudo you almost got it:
The essential internal method interfaces (defined in Table 4 and 5) are essential because they are used to define the runtime semantics of the Object Type manipulating syntactic language features (and built-in library). Section 10.1-10.3 defines the the ordinary (i.e. default) implementation of the the essential internal method interfaces. Section 10.4-10.5 defines other exotic implementations of those interfaces that are used for various objects in the built-in library.
ECMAScript implementations and hosts (e.g. web browsers) might defines other exotic implementations of the essential internal method interfaces but those are outside of the prevue of ECMA-262.
Stepping back a ways, the essential internal method interfaces are the Metaobject protocol of the ECMAScript language.
nicolo-ribaudo commentedon Aug 13, 2026
We discussed this in the editor call, and we're leaning towards keeping both concepts ("essential internal method" and "internal method"), but marking [[Call]] and [[Construct]] as not essential since they are not guranteed to exist on all objects.
allenwb commentedon Aug 13, 2026
Something I haven't seen mentioned is that the name "essential internal methods" is acts a link to the requirements specified in 6.1.7.3 Invariants of the Essential Internal Methods. Some of those requirements apply to [[Call]] and [[Construct]]. So if [[Call]] and [[Construct]] are not essential internal methods then it is also going to require some changes to that section.
I think a simpler clarification of the original issue could be achieved as follows.
In section 6.1.7.2 modify the following paragraph as shown below:
Move the paragraph that is currently between Table 4 and Table 5 so it immediately follows the above paragraph and make the modifications shown here:
It might also make sense to move the final (after Table 5) paragraph of 6.1.7.2 so that it comes after the paragraph that begins:
nicolo-ribaudo commentedon Aug 14, 2026
Thank you for the suggestion.
So to recap, there are three different concepts:
Right now, the spec calls:
I would like to disambiguate the spec on whether essential internal methods are (2) or (3). Your proposed change clarifies that essential internal methods is (2), which is fine for me. I'll open a PR with it.
Yesterday in the editor call we couldn't come up with an example of something that is in (1) but not in (2), so it wasn't clear that we even need that distinction. However, it seems like the streams spec does define some extra internal methods (https://streams.spec.whatwg.org/#rs-default-controller-internal-methods).