Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53564
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.238 as permitted sender)
To: Jan Schneider <jan@horde.org>, "internals@lists.php.net"
	<internals@lists.php.net>
Date: Fri, 24 Jun 2011 00:34:08 -0400
Thread-Topic: [PHP-DEV] foreach() for strings
Thread-Index: AcwxjGtzmPWthTqlSkeOP9Uynr52EwAlhT0Q
Message-ID: <A633CF2D7C7BED41B41F1E64F25507B80604884C33@MAILR001.mail.lan>
References: <BANLkTi=qbj_=dmNv__RN4LkDY4GgbTtGYQ@mail.gmail.com>
 <BANLkTikipDXeO-wj0gch__6PErqcbGZfmA@mail.gmail.com>
 <A633CF2D7C7BED41B41F1E64F25507B8060488499D@MAILR001.mail.lan>
 <4E02D95F.7030303@garfieldtech.com>
 <20110623114012.Horde.RFhDBxPcj3hOAwn8LIYjSMA@neo.wg.de>
In-Reply-To: <20110623114012.Horde.RFhDBxPcj3hOAwn8LIYjSMA@neo.wg.de>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] foreach() for strings
From: johncrenshaw@priacta.com (John Crenshaw)

> -----Original Message-----
> From: Jan Schneider [mailto:jan@horde.org]=20
>
> And if that very same string that's supposed to be an array is =20
> processed using the $var[$n] syntax nowadays is any different? It's =20
> not, you won't get an error message for that either, and it's the same =20
> amount of work to track this down. Granted, making PHP behaving the =20
> same in foreach gives you one more place to track down such errors, =20
> but making it easier to track down developer errors is not anything =20
> that should keep PHP from adding new features.
>
> Jan.

In theory, yes, but in practice this doesn't seem to happen with any freque=
ncy (actually, I'm having a hard time thinking of a time when this has EVER=
 happened to me.) On the other hand, warnings about foreach getting somethi=
ng that wasn't iteratable are commonplace for me, and more often than not, =
it is a string.

I think it's perfectly appropriate for any language to avoid "high risk" fe=
atures (features that are likely to result in buggy code, or features that =
are likely to result in bugs evading detection.) My code has enough bugs al=
ready, so any language feature that finds my bugs for me is more than welco=
me.

Consider implicit vs. explicit returns. If a function always returns the va=
lue of the last statement (implicit) this is likely to result in unpredicta=
ble behavior and hidden bugs, when a warning could have been issued instead=
. Typing "return" clarifies intent and is a very small price to pay to avoi=
d those errors. In this case, typing "new TextIterator()" in the handful of=
 cases where you actually needed to iterate a string is a VERY small price =
to pay for:
1. The ability to get meaningful warnings when you didn't intend to iterate=
 the string (by far the more likely scenario)
2. The ability to easily fix your code when you decide that a universal cha=
racter set really is valuable
3. The ability to clearly see the intent of the code

John Crenshaw
Priacta, Inc.