RE: [PHP-DEV] foreach() for strings

> -----Original Message----- > From: Jan Schneider [mailto:jan@horde.org] > > 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. In theory, yes, but in practice this doesn't seem to happen with any frequency (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 something 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" features (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 already, so any language feature that finds my bugs for me is more than welcome. Consider implicit vs. explicit returns. If a function always returns the value of the last statement (implicit) this is likely to result in unpredictable 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 avoid 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 character set really is valuable 3. The ability to clearly see the intent of the code John Crenshaw Priacta, Inc.