<div dir="ltr">I didn't forget in the post, neither is necessary here, I put in the post to deal with an integer but that's superflous for the purpose so no mistake (we all know arr["1"] is gonna be handled as arr[1], as example)<div>
<br></div><div style>Anyway, RegExp.$N is just fine and standard across all engines I know and RegExp#test() is more semantic than re.exec() plus it returns a boolean rather than compare a truthy/falsy value so .test() is correct if you expect exactly a boolean, not possible to be that explicit otherwise with exec.</div>
<div style><br></div><div style>The creation of an array can be not necessary and I code for mobile and Raspberry where RAM is gold and less GC kicks or less greedy too.</div><div style><br></div><div style>Accordingly, I will keep using RegExp.$N as long as every single engine will support it, without being forced by your personal taste to create a useless object plus we all know how many other problems a var in the scope could cause ... compare a var in the wild against RegExp access .. how better is really that?</div>
<div style><br></div><div style>Of course there are cases where exec is better, more readable, etc, and you have all these cases and reasons behind, in these good old slidess: <a href="http://webreflection.blogspot.de/2012/02/berlin-js-regexp-slides.html">http://webreflection.blogspot.de/2012/02/berlin-js-regexp-slides.html</a></div>
<div><br></div><div style>I was missing the Brendan suggested property there and others, so I might update those slides.</div><div style><br></div><div style>Now, this thread is about something else, so that was just an alternative that makes the function portable and reusable, something the outer scope, your preferred solution, cannot do without polluting the scope and cannot be portable across different closures too ... but sure, I have to be humble while you cannot recognize your pattern might be undesired and not as flexible as mine, right ?</div>
<div style><br></div><div style>Mine is ugly? It's OK, it's an alternative .. and **it works**.</div><div style><br></div><div style>Now I am off this conversation,</div><div style>    Best Regards.</div><div style>
<br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 4, 2013 at 3:15 PM, Jeff Walden <span dir="ltr"><<a href="mailto:jwalden+es@mit.edu" target="_blank">jwalden+es@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 03/04/2013 08:38 AM, Andrea Giammarchi wrote:<br>
> I believe creating a redundant array of matches for no reason since these are retrievable in any case through the RegExp constructor, considering exec and match points to those RegExp properties anyhow, ain't needed when re.test(value) is involved.<br>

<br>
</div>You're saving on array-construction and element-creation, but you're losing (with many to most current engines) on having to re-run the regular expression a second time to compute the match components.  You're almost certainly going to lose out overall when you take this extra cost into account.  Array and string creation are fast in engines these days.  Regular expression matching with the intent of constructing statics info is not.<br>

<br>
Your code's also fragile against introduction of any other regular expressions within the code being demonstrated there.  If someone copies your code and tries to change the === to a function-based test, they might well change it to something that uses regular expressions.  That person might even be you: what's obvious now may not be obvious in the future.<br>

<div class="im"><br>
> If re.test(value) RegExp.$1;<br>
><br>
> As easy as that: 1) is *not* a bad practice and 2) is less redundant than if (re.test(value)) match = re.exec(value)[1];<br>
<br>
</div>To clarify the above, it's better to do:<br>
<br>
var results = re.exec(value);<br>
if (results)<br>
  results[1];<br>
<div class="im"><br>
> those properties I believe defined in the specs does not mean those properties are bad (as I have just explained)<br>
<br>
</div>They are not defined in spec, partly because you're mistaken about them being a good idea.<br>
<div class="im"><br>
> Also, that does not find a thing, that find an index ...<br>
<br>
</div>It's a fair point.  Although, given non-existence, it would seem to me you'd only want a method that returns an index, and then getting the element value is just arr[index] at that point.<br>
<div class="im"><br>
> We are programmers, we find solutions/alternatives/optimizations ... right?<br>
<br>
</div>I'd also suggest we have the humility to recognize when we're trying to be too clever by half, as your forgotten "+" demonstrates.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jeff<br>
</font></span></blockquote></div><br></div>