Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: "Christoph M. Becker" <cmbecker69@arcor.de>
Newsgroups: comp.lang.javascript
Subject: Re: JSlint finds for loops intolerable
Date: Sat, 3 Sep 2016 20:54:06 +0200
Organization: solani.org
Lines: 43
Message-ID: <nqf67r$8uj$1@solani.org>
References: <npug18$166s$1@gioia.aioe.org> <npuldh$q9l$1@solani.org> <3919372.LvFx2qVVIh@PointedEars.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: solani.org 1472928827 9171 eJwFwYEBwEAEA8CZCHnGQdl/hN45KJxndJqfn4oIePd02/S6ULEchCIL21Mew5Rc/XLIHxuUETY= (3 Sep 2016 18:53:47 GMT)
X-Complaints-To: abuse@news.solani.org
NNTP-Posting-Date: Sat, 3 Sep 2016 18:53:47 +0000 (UTC)
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
X-NNTP-Posting-Host: eJwFwQkRADAIAzBLdFAeOYMb/iUsoTp8wpxuXC7QYTWYZiok1W4syjfZJmT2q5pzlGL6bnwCyRAV
In-Reply-To: <3919372.LvFx2qVVIh@PointedEars.de>
X-User-ID: eJwFwYEBwCAIA7CXyqAdnOOc/f8EE6ZC+y1RRdNHlefRxKo24oc4PXJOxm6Um/jgACCtWBf/DQ/b
Cancel-Lock: sha1:WtFOW43JWM6NZZYqomVqPFv9MwM=
Xref: csiph.com comp.lang.javascript:31222

On 30.08.2016 at 12:11, Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> Once you get the hang of using Array.prototype.forEach(), you'll
>> probably find many places where a more specific array method is more
>> appropriate (for instance, .filter() and map()), and these can simplify
>> the code (even more).
> 
> Yes, but:
> 
> Efficiency issues aside (while the callback is usually compiled only once, 
> there is a *function call* for *each* iteration), one has to be really 
> careful when refactoring loops to calls to iterating Array prototype methods 
> because then in the callback you are in a *function* where things work 
> differently.
> 
> For example, it will be difficult to impossible to convert a “for” or 
> “while” loop that uses the ”break”, “continue” or “return” statements to 
> *equivalent* callback code: “break” and “continue” are not allowed outside 
> of loops.  “return” in a callback is equivalent to a “continue” without 
> label, but there is no elegant equivalent for ”break” (keeping to call the 
> callback and querying a non-local flag so that the callback returns early is 
> _not_ elegant IMO), and “return” returns *from the callback*, _not_ from the 
> function that called the Array method, so there is no elegant equivalent for 
> that either.

Indeed, good caveats!  However, one can come a long way without using
`break`, `continue` or early `return`, and I often prefer that, except
when performance is of utmost importance.  One rather common use of
`break`, for instance, is for (linear) searching/checking;
Array.prototype.every() resp. Array.prototype.some() can be alternatives.

> One also has to deal with the fact that the “this” value in the callback is 
> either the “undefined” value (strict mode) or a reference to the global 
> object (otherwise) by default. […]

In my humble opinion, the dynamic binding of `this` has been a most
unfortunate design decision, even though it allows for some interesting
programming techniques (such as borrowing).

-- 
Christoph M. Becker