(Resolved) "typeof" on various callable things

[lth]

ES3 (Firefox 2.0.0.7):

   typeof Object => "function"
   typeof /abc/  => "function"

ES3 (Opera 9.23 and MSIE 6.0.2900):

   typeof Object => "function"
   typeof /abc/  => "object"

There are two views.

One view is that typeof returns "function" for any object x s.t. "x is Function". Remember that Function.prototype is on the prototype chain of every class object; logically speaking, therefore, the metaclass for Object -- the class that determines what the Object object looks like -- is a subclass of Function. If Function did not have the restriction it currently has that its meta::invoke is final (see separate ticket for this), then that view would be pretty much perfect: a "static meta invoke" method is a "meta invoke" method on the metaclass, which overrides the one inherited from Function. We're done.

The other view is that anything Callable (has a meta::invoke fixture) is "function". This means RegExp gets to be "function" like in Firefox, but I think this is an edge case, probably.

[brendan]

Firefox 3 throws in the towel and makes typeof /abc/ == "object" to match IE et al.

ES3 11.4.3 seems clearly to take the "other view" (anything Callable): "Object (native and implements [[Call]])" has typeof "function". It leaves host objects to do whatever they please, which isn't helpful.

No engine except for SpiderMonkey? has tried to follow the spec here, as far as I know, and no good deed goes unpunished. De-facto trumps de-jure, I say. Let's codify what browsers (Firefox 3 and up) do and get on with our lives. There's more to life than typeof ;-).

/be

[lth]

I can't really tell what you're proposing, but since you're backtracking on how FF does RegExp? objects, I assume you are proposing that "typeof x => 'function'" iff x is an instance of (a subtype of) Function.

[brendan]

Sorry, I was not clear, but my intention was clear enough that you assumed correctly, except that in embeddings with multiple global objects, it is important to say that typeof x => "function" means (x instanceof g.Function) and (x is g.Function) for some global object g. That's all -- could be a different g from the one at the end of the current execution context's scope chain.

/be

[lth]

What Brendan said.

[airforce1]

thanks get a nice air force ones

[add]

Iron decorates your home. They have a wide variety of design, assuring that you will find a special one for display at home. The metal stai http://www.hebei-railings.cn/

[David-Sarah Hopwood]

Discussion above is very ES4-specific, so marking as invalid. Need another issue for what typeof(callable_native_nonfunction) should be in ES3.1 (if callable native nonfunctions are allowed at all). Obviously it is not good if what SpiderMonkey? has decided to do is not conformant to ES3.1, as appears to be the case at the moment.

[brendan]

We've been over this before, you know the history, so please stop playing at revising it. SpiderMonkey? has had callable regexps since the following log-message's revision to cvs.mozilla.org's mozilla/js/src/jsregexp.c file:

revision 3.2 date: 1998/04/24 00:30:07; author: fur; state: Exp; lines: +163 -94 Initial checkin of JavaScript? 1.3, migrated from JSFUN13_BRANCH in /m/src repository

Over ten years. ES3.1 didn't exist until 2008. Therefore writing "what SpiderMonkey? has decided to do is not conformant to ES3.1", which suggests SpiderMonkey? changed to flout ES3.1 order, is misleading at best.

SpiderMonkey? bugs go to https://bugzilla.mozilla.org/ -- not here.

The tracspam in this ticket is enough to kill it.

/be

[David-Sarah Hopwood]

I meant what SpiderMonkey? recently decided to do, in changing typeof /re/ from "function" to "object". This is nonconformant to both ES3 and the ES3.1 draft, given that RegExp? objects have a

Error: Failed to load processor Call

No macro or processor named 'Call' found

method in SpiderMonkey?. That is either a spec bug in ES3.1 or an implementation bug in SpiderMonkey?. If the former, it should be a separate ticket here; if the latter, it should be at bugzilla.mozilla.org.

(And no, spam is not enough to kill a Trac ticket, otherwise it would kill practically every ticket here. Just ignore the spam, it won't bite you.)

[David-Sarah Hopwood]

Hmm, that clash between ES internal method names and Trac macro syntax is rather unfortunate.

[brendan]

There you go again: SpiderMonkey? "recently" decided to restore web compatibility for typeof /re/ well before ES3.1 was even drafted.

It doesn't matter what ES3 says, since we were stuck with callable regexps. Yes, we did not conform to ES3 in adding callable regexps *ten years ago*, but that does not change the order of events.

Compatibility of one implementation aside, I see no ecmascript.org issue here worth belaboring.

The tracspam was due to the authenticated group being infected by a bad id. It should not recur. If it does the tool will become unsable. Don't tolerate it.

/be