Throwing StopIteration in array extras to stop the iteration
andrea.giammarchi at gmail.com
Mon Mar 4 15:31:59 PST 2013
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, 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
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:
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,
On Mon, Mar 4, 2013 at 3:15 PM, Jeff Walden <jwalden+es at mit.edu> 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);
> To clarify the above, it's better to do:
> var results = re.exec(value);
> if (results)
> > 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 ...
> I'd also suggest we have the humility to recognize when we're trying to be
> too clever by half, as your forgotten "+" demonstrates.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss