Draft of Function.prototype.bind.
brendan at mozilla.com
Mon Nov 3 22:06:09 PST 2008
On Nov 3, 2008, at 8:51 PM, Mark S. Miller wrote:
> On Mon, Nov 3, 2008 at 7:08 PM, Brendan Eich <brendan at mozilla.com>
> > See also 11.4.3 The typeof Operator (second to last table row).
> For reference, the last three rows of that table are
> Object (native and doesn't implement [[Call]]) "object"
> Object (native and implements [[Call]]) "function"
> Object (host) Implementation-
> So it's pretty clear from the text you cite that typeof of a native
> object that implements [[Call]] must be "function".
No, it must have typeof-type "function" -- that is not the same as
being a function object -- as having internal [[Class]] property value
"Function" (13.2 step 3).
Let's agree (I do, with your words at the end of your message) to use
"a function" to mean "a function object", that is, "an object whose
[[Class]] is ''Function''." But the typeof spec is not talking about
the value of the object's [[Class]] internal property at all.
Put another way, all function objects are callable but not all
callables are function objects.
Consider Python and many similar languages; consider too the bridging
between DOM, Java, Python, and other runtimes where callables that are
not anything like JS functions must have object reflections in JS.
Such reflection objects are not required by ES1-3 to have typeof-type
"function" and it's more useful in our experience to give them typeof-
> On FF3.0.3, a bit of testing reveals that RegExp instances are
> indeed callable as functions, which presumably means they have an
> internal [[Call]] property. And they are clearly native objects, not
> host objects. However, unlike Rhino or WebKit, of FF3.0.3 at least,
> typeof of a RegExp does return "object". I don't see any way to
> rationalize this as conforming to the spec. Since WebKit conforms to
> the ES3 spec in this regard, it would seem that one can both follow
> this clause of the spec and not break the web.
First, this has nothing to do with whether all callables are function
Second, the reason we retreated on following ES1-3's spec for typeof
here was precisely compatibility, both Web and Mozilla platform
compatibility. See these bugs:
Third, the issue of whether RegExp having a [[Call]] internal property
is a good idea is separate from any of this "all callables should be
function objects" argument. Let's agree that callable regexps are a
Nevertheless, the ES1-3 specs allow this extension, in particular the
typeof sub-spec specifies that such callable native objects as
callable RegExp instances have typeof-type "function". We tried that,
it broke too many pages that want what other browsers do.
There were two possible fixes: removing RegExp's [[Call]] internal
property; changing how typeof works on a native object. We picked the
latter because of too much Mozilla-specific code that depended on
RegExp instances being callable. See Alex Fritze's comments in https://bugzilla.mozilla.org/show_bug.cgi?id=289933
Again, this callable regexp story is a sideshow. It's about typeof. It
is not relevant to the question of whether all callable native objects
must be function objects. Just based on the ES1-3 specs, and taking
chapter 16 of ES3 into account, it's clear that *not* all callable
native objects must be function objects -- objects whose [[Class]] is
> If F is a callable native object, then the section of the spec
> Brendan cites (and which FF violates) does guarantee that |typeof F|
> be "function". Whether we want to describe such objects as functions
> in prose about them is another matter. In descriptive prose, I
> prefer to describe as functions only native objects whose [[Class]]
> property is "Function".
Yes, that is the definition used consistently (or nearly so) in the
spec. We should fix any deviations, and strive to use "callable" for
the general term and "function" only for objects whose [[Class]] is
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss