Proposed change to typeof (was: Draft of Function.prototype.bind)

Mark S. Miller erights at
Tue Nov 4 10:11:21 PST 2008

On Mon, Nov 3, 2008 at 10:55 PM, Maciej Stachowiak <mjs at> wrote:

> I'm sure people may have an opinion one way or the other, I just don't know
> of any Web content actually broken by this in practice. I don't have strong
> feelings on the matter in either direction, just reporting our experience.

For Cajita, the only issue is RegExps. Host objects are such a disaster of
unspecified vagueness and random browser behavior that we never expose hosts
objects directly to cajoled code. Rather, we intermediate all access to host
objects through our taming layer. Other secure JS variants -- ADsafe, FBJS,
Jacaranda, MS WebSandbox, -- do likewise.

Within Cajita, RegExps are non-callable and are not functions, irrespective
of the underlying JS's behavior. Therefore, within Cajita, |typeof F ===
'function'| iff the [[Class]] property of F is "Function". In Cajita,
therefore, there is no difference between "being callable" and "being a

Because Rhino and WebKit say that typeof a RegExp is 'function', we need to
translate all Cajita typeof operations. Because Valija -- the full
ES3.1-strict emulation layer build on Cajita -- uses typeof in performance
critical places, this translation turned out to be costly.

I suggest that, for non-host objects, we change the ES3.1 spec so that
|typeof F === 'function'| iff the [[Class]] property of F is "Function". For
host objects, the spec would continue to allow them to return whatever the
func they want ;). This proposed change is acceptable to all participants on
this morning's ES3.1 call, pending your reactions on these lists.

Practically, the only difference this will make is to mandate that typeof a
RegExp be "object", not "function", whether or not RegExps are callable on
that platform. Given that this matches IE's and FF's current behavior, this
change will not break the web. This would have the unpleasant consequence of
causing WebKit and Rhino to become out of conformance with ES3.1 because
they correctly implemented this clause of ES3. If they do not object, does
anyone see any other downsides to this suggestion?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list