Callable RegExp vs. typeof (was: Re: Draft of Function.prototype.bind.)
lsmith at lucassmith.name
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
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