Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)

Juriy Zaytsev kangax.dev at gmail.com
Thu Aug 13 13:59:18 PDT 2009


On Aug 13, 2009, at 4:44 PM, Brendan Eich wrote:

> On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote:
>
>> There was a discussion of this ticket on Hacker News this morning  
>> and we had this slight confusion on whether giving RegExp objects a  
>> [[Call]] property is permitted by spec <http://news.ycombinator.com/item?id=760529 
>> >. I thought it was, since section 2 clearly states that  
>> implementation can introduce its own extensions, but then someone  
>> made a point about exact wording in that section and how it seems  
>> that implementation can only add properties that spec doesn't  
>> mention (i.e. additional ones) and not those that spec mentions  
>> (such as [[Call]]) but doesn't specify them on certain objects.
>>
>> Could someone please clarify this?
>
> Good point. I seem to recall that David-Sarah Hopwood made it  
> already, but I'm having trouble finding his message right now.
>
> ES3 Chapter 16 says:
>
> "An implementation may provide additional types, values, objects,  
> properties, and functions beyond those described in this  
> specification. This may cause constructs (such as looking up a  
> variable in the global scope) to have implementation-defined  
> behaviour instead of throwing an error (such as ReferenceError)."
>
> As the ycombinator thread correspondent says, this is ambiguous:  
> does "may provide ... properties ... beyond those described by this  
> specification" mean [[Call]] on a native object specified without  
> [[Call]] by ES3 is ok? Or does it mean that only properties whose  
> identifiers are not defined at all for any object may be added? Or  
> should internal properties be excluded in any event?
>
> The practical issue of typeof /a/ == "function" being misleading and  
> causing compatibility problems is paramount. Fixing that by ruling  
> that extending RegExp to have a [[Call]] internal property violates  
> ES3 is plausible in theory, but again in practice hard if enough  
> content depends on /a/(s).

Thank you.

Whatever the consensus is, could the relevant section in ES5 be made  
less ambiguous in regards to internal properties (perhaps with an  
example of [[Call]] being allowed/disallowed on objects that don't  
explicitly have it)?

-- 
kangax


More information about the es-discuss mailing list