Strategies for standardizing mistakes
jimb at mozilla.com
Wed Oct 14 16:40:28 PDT 2009
On 10/13/2009 04:05 PM, Mike Shaver wrote:
> 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 think David-Sarah may have overstated his case when he used the phrase
"arbitrary additional inputs depending on the context in which they are
used". Of course host objects interact with the host environment, and
have access to various kinds of state like privileges and preferences.
There's one specific kind of contextual information that's being looked
at askance here: knowledge of the expression surrounding the call that
invoked you. Perl lets subroutines check what sort of value their
caller is expecting; that hasn't aged well.
It seems to me that ES5 is not capable of forbidding such behavior. ES5
can't forbid implementations from providing JS debugging APIs, nor
forbid such APIs from providing functions that inspect a call, nor
forbid host objects from using such a function.
More information about the es-discuss