Zitat von Larry Garfield <la...@garfieldtech.com>:
On 06/20/2011 10:25 AM, John Crenshaw wrote:
Doing this with an explicit iterator object is a fine idea. The
syntax becomes something like:
foreach(new TextIterator($s, 'UTF8') as $pos=>$c)
{
...
}
On the other hand, I think that trying to support iteration without
using an iterator object to mediate would be a disaster, and I'm
opposed to doing something like that because:
1. The code just looks wrong. PHP developers are generally
insulated from the char-arrayness of strings. In addition, since
PHP isn't typesafe, the code becomes highly ambiguous. Is the code
iterating an array, or a string? It is very hard to tell just by
looking. It may be convenient to write, but it's certainly not
convenient to read or maintain later. On the other hand, with a
mediating iterator object, the intent becomes obvious, and the code
is highly readable.
2. The odds of iterating any given string are slim at best.
Supporting current, key, next, etc. would require the string object
internally to get bloated with additional unnecessary data that is
almost never used. This bloat isn't a single int either. For
optimal performance it would need to consist of no less than two
size_t (char position and binary position), and one encoding
indicator.
3. Iteration cannot work without knowing which encoding to use for
the string. Is it UTF8? UTF16? UTF7? Binary or some single byte
encoding? Some other exotic wide encoding? Without an iterator
object in the middle, there is no way to specify this encoding.
Always treating this as binary would also be a mistake, since this
is almost certainly never actually the correct behavior, even
though it may often appear to behave correctly with simple inputs.
4. I've had simple mistakes caught numerous times when foreach
complains about getting a scalar rather than an array. So far, it
has been exactly right every time. Allowing strings to be iterated
would, in the name of convenience, increase the probability of
stupid mistakes evading detection. Even worse, the code itself
would look logically correct until the developer finally realizes
that they have a string and not an array. Errors like this are
probably far more common in most projects than the need to iterate
a string, so making this change hurts debugging in the common case,
for the sake of syntactic sugar in the rare case. Not a good trade.
John Crenshaw
Priacta, Inc.
I would echo John's statements here. foreach() directly iterating a
string is going to make my life substantially harder. I work in
array-heavy systems, and "bad first argument for foreach()" is
already a hard enough error to track down. It means "somewhere,
somehow, you put a string where you meant to put an array. GLWT."
Adding automatic string iteration would take away even that error
message and leave me with no way to figure out why my code is
randomly misbehaving. Just looking at the code, I would have no way
of knowing that such a bug lurks within. That's the downside of a
weakly typed but still typed language.
And if that very same string that's supposed to be an array is
processed using the $var[$n] syntax nowadays is any different? It's
not, you won't get an error message for that either, and it's the same
amount of work to track this down. Granted, making PHP behaving the
same in foreach gives you one more place to track down such errors,
but making it easier to track down developer errors is not anything
that should keep PHP from adding new features.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
