>-----Original Message-----
>From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
>boun...@mozilla.org] On Behalf Of Mike Shaver
>Sent: Tuesday, October 13, 2009 4:05 PM
>To: David-Sarah Hopwood
>Cc: es-discuss@mozilla.org
>Subject: Re: Strategies for standardizing mistakes
>
>On Tue, Oct 13, 2009 at 7:01 PM, David-Sarah Hopwood
><david-sa...@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  
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to