Strategies for standardizing mistakes

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Wed Oct 14 16:08:26 PDT 2009


>-----Original Message-----
>From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of Mike Shaver
>Sent: Tuesday, October 13, 2009 4:05 PM
>To: David-Sarah Hopwood
>Cc: es-discuss at mozilla.org
>Subject: Re: Strategies for standardizing mistakes
>
>On Tue, Oct 13, 2009 at 7:01 PM, David-Sarah Hopwood
><david-sarah at jacaranda.org> wrote:
>> I agree with Maciej. The implementation-defined operations have clear
>> specifications of their parameters. I think that it is highly
>undesirable
>> to adopt an interpretation in which they can have arbitrary additional
>> inputs depending on the context in which they are used.
>
>If they didn't depend on the context in which they are used, they
>wouldn't need to be host objects, right?  The whole point of the host
>object is that it knows things about the host (what mode it was loaded
>in, what privileges the context offers, what the user's preferences
>are) which aren't within the scope of the language proper.
>

I agree with Mike (and hence disagree with Maciej and David-Sarah).  The internal methods are not implementation devices, although actual implementation might actually use a similar seeming mechanism.  The internal methods are just specification devices uses for describing the standard semantics and their arguments are simply devices used in factoring the pseudo-code of the specification.  When the spec. says that host object's may use other definitions of the internal methods, they are saying that the semantics is arbitrarily defined by the implementation when host objects appear in such contexts.  There is nothing in the specification that limits implementations limited to using information provided by the pseudo-code arguments in the definition of their semantics. The implementation can do anything including making use of data or oracles that are not explicitly provided for in the ES specification.

Fundamentally, I think the misunderstanding here is similar to the one Cameron had when drafting the WebIDL spec.  Internal methods are not a general purpose extension mechanism for plugging new functionality into ES.  They simply provide a convenient mechanism in the specification for specifying polymorphic semantics. You can use them in defining the semantics of extensions, particularly ones that are tied to specific types of objects.  However, they aren't intended to constrain future semantic extensions.  That why ES5 was free to both add new internal methods and change both the definition and signatures of some previously existing internal methods.  They aren't the language, their just a tool used to specify the language.

Allen  


More information about the es-discuss mailing list