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

Luke Smith lsmith at
Thu Aug 13 14:07:28 PDT 2009

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

> 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).

Certainly the story is muddied by supporting /a/(str) and reporting  
typeof /a/ == 'function', but limiting the types of invocation  
available vs those available to actual functions.  No constructor  
invocation, apply invocation, etc, and in fact  
hostObj.myRegExpObj(str) 'this' is presumably always the RegExp  
instance.  Comprehending function invocation is confusing enough for  
js developers.

Practically, I see no value in the extension, since it is just  
shorthand for an existing API.  And the fact that it has repercussions  
elsewhere in the runtime is another point against it.


More information about the es-discuss mailing list