[Webkit-unassigned] [Bug 28285] Remove non-spec support for callable RegExp

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=28285





--- Comment #3 from Luke Smith <lsmith at lucassmith.name>  2009-08-14 16:05:08 PDT ---
(In reply to comment #2)
> The spec states "Unless specified otherwise, the [[Class]] property of a
> built-in object is "Function" if that built-in object has a [[Call]] property,
> or "Object" if that built-in object does not have a [[Call]] property."
> 
> This would seem to pretty clearly imply that an object of a class other than
> "Function" can validly implement [[Call]] (provided that it is stated as such),
> and therefore assuming that an object with a [[Call]] property is specifically
> of class Function is incorrect.
> 

I agree that by that wording it is valid to add [[Call]] to RegExp, as the
"Unless stated otherwise" allows for RegExp [[Class]] defined in 15.10.4.1.

> To test for a function you can just use the instaceof operator:
> 
> if (v instanceof Function)

Unfortunately not true.  If v is a function from another frame, it is not
instanceof Function as defined in the current frame.


> Hmmm, section 11.4.3 seems pretty clear, and I certainly can't agree with
> FireFox's implementation here.  The spec very clearly states that for any
> native object that implements [[Call]] the typeof operator must return
> "function".  So far as I'm aware, this is the only way within the language to
> ask this specific question (is this any kind of object that can be called as a
> function, as opposed to, is this object an instance of "Function"), and it
> doesn't seem like a capability we'd want to take away.  So I can't say that I
> think we want to unify on FireFox's present behaviour here.  I believe WebKit's
> current behavior is sensible, and is not fundamentally at conflict with the
> spec (and it would also be a sensible and consistent state to remove the
> ability to call RegExp objects as functions).
> 
> I would suggest the FireFox's RegExp implementation is presently noncompliant
> with the spec in that it violates section 11.4.3 - a native object with a
> [[Call]] property fails to return "function" from typeof.  It would probably be
> helpful to file a bug with them.

This is discussed in the originating bug 28117 (not 281117 as I fat fingered
above).
https://bugs.webkit.org/show_bug.cgi?id=28117

Specifically, the following bugs were filed with Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=61911
https://bugzilla.mozilla.org/show_bug.cgi?id=289933

I also agree that per the spec, reporting typeof /a/ == "function" is correct
if RegExp has been extended with [[Call]] and that Firefox, Opera, and Chrome
violate the spec by implementing the feature and reporting "object".  However,
the practical ramifications of reporting "function" were enough to convince
each of these vendors to do so.  Callable RegExp were not present in Chrome 2
but are in Chrome 3, and despite its close (historical at least) relationship
to WK, it diverged from WK's behavior in favor of FF and Opera's.

My concern is that following the spec in this regard when 3 other vendors agree
not to creates another inconsistency for developers to deal with.  Firefox,
Chrome, and Opera's choice also brings their typeof reporting into alignment
with IE (in this respect) who do not implement callable RegExp.  So of 5 major
browser vendors, WebKit's behavior wrt typeof /a/ is unique.

There is more active discussion on this topic on es5-discuss:
https://mail.mozilla.org/pipermail/es5-discuss/2009-August/003033.html

> 
> > new obj.someRegExp(str) => boom
> 
> If I'm understanding your test case correctly, you seem to be assuming that all
> objects that have a [[Call]] property must also have a [[Construct]] property?

No, I understand the behavior.  I'm just suggesting that it's already
challenging to teach the nuances of js function invocation to new developers. 
Having something else that can look like a function
obj(str)

but not be a function just muddies the waters.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.