Add call and apply methods to RegExp.prototype
Brendan Eich
brendan at mozilla.org
Fri Dec 21 16:06:56 PST 2007
On Dec 21, 2007, at 7:33 AM, StevenLevithan wrote:
> Yes, its easy to pull off oneself, so I don't care much other way.
> Still, it
> seems pretty weird to me to be able to do ``regex(str)`` but not
> ``regex.call(context, str)``. This is accentuated when typeof returns
> "function" for regexes (though it seems ES4 will change this to
> "object").
Hey Steve, Yuh-Ruey (I owe both of you replies to the list, for Steve
agreeing about ES3 capturing paren broken design, Yuh-Ruey on fine
points about instanceof, etc. -- I wanted to drop a note here,
quickly, and catch up next week while I'm off).
The callability of RegExp has been a sore point to some (Garrett
Smith at least sees no benefit), and it led SpiderMonkey, which has
made RegExp instances callable since the last millennium, to follow
the exact letter of ES3 and therefore have typeof /hi/ == "function".
This deviates from other browsers, creating interop problems, and
Firefox 3 (JS1.8) no longer follows ES3 here. For the same reason,
ES4 is changing ES3 to say that typeof x == "function" iff x
instanceof Function for some global object's Function constructor.
Given this back-off on the typeof front, and the more significant
fact that !(/re/ instanceof Function), which we cannot change, I have
to ask: is RegExp callability worth it?
Calling a regexp instead of invoking its .exec method is convenient
enough once you get used to it, but .exec is only five more
characters, and some people (sorry for forgetting exactly who they
are) point out that calling a RegExp might rather be defined as a
call to .test (to avoid creating the returned array -- here again an
implementation can optimize based on the continuation of the call to
the regexp object -- SpiderMonkey does this).
If we keep regexp callability in ES4 as a new convenience, then I
agree we should think about call and apply. People can use
Function.prototype.call, or in ES4 Function.call the static helper,
but you end up passing the regexp twice (as the callee and the |this|
parameter): Function.call(regexp, regexp, input) instead of simply
regexp(input).
This raises the question: since there is only one argument to exec or
test, so why do you ever need to delegate invocation using apply or
call? The only case that comes to mind is a generic programming use-
case where you might have either a function object or a regexp and
you want to .apply it with an argument array. But again, you could
just invoke foo(arg) given foo denoted either a function or a regexp.
True, the most generic program would not want to hardwire argument
count, so would want .apply. But still, the motivation for call and
apply in RegExp.prototype seems weak.
Note that in Steve's example, regex.call(context, str), context
*must* be a RegExp instance. There's no benefit to using .call
or .apply over just regex(str) if you know you're passing exactly one
(input string) argument.
Summarizing my questions:
1. Is regexp callability worth adding in ES4?
2. If yes to 1, do we really need .call and .apply?
I'm leaning toward no/no, could be content with yes/no, do not
believe yes/yes based on the above reasoning.
/be
> Yuh-Ruey Chen wrote:
>>
>> Sounds like a good idea to me. On the other hand, this can already
>> easily be done in ES3.
>>
>> Steven L. wrote:
>>> ES4 proposals include making regexes callable as a function on a
>>> single string argument, which serves as a shorthand for calling the
>>> regex's exec method. To further extend this idea, what about also
>>> including call and apply methods on RegExp.prototype ...
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Add-call-and-
> apply-methods-to-RegExp.prototype-tp14429329p14457280.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list
> archive at Nabble.com.
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
More information about the Es4-discuss
mailing list