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)
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. 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. 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? 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: http://webreflection.blogspot.de/2012/02/berlin-js-regexp-slides.html I was missing the Brendan suggested property there and others, so I might update those slides. 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 ? Mine is ugly? It's OK, it's an alternative .. and **it works**. Now I am off this conversation, Best Regards. On Mon, Mar 4, 2013 at 3:15 PM, Jeff Walden <[email protected]> wrote: > On 03/04/2013 08:38 AM, Andrea Giammarchi wrote: > > 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. > > 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. > > 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. > > > If re.test(value) RegExp.$1; > > > > 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]; > > To clarify the above, it's better to do: > > var results = re.exec(value); > if (results) > results[1]; > > > those properties I believe defined in the specs does not mean those > properties are bad (as I have just explained) > > They are not defined in spec, partly because you're mistaken about them > being a good idea. > > > Also, that does not find a thing, that find an index ... > > 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. > > > We are programmers, we find solutions/alternatives/optimizations ... > right? > > I'd also suggest we have the humility to recognize when we're trying to be > too clever by half, as your forgotten "+" demonstrates. > > Jeff >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
