2006/6/6, Robert Cummings <robert@xxxxxxxxxxxxx>:
On Tue, 2006-06-06 at 13:11, Martin Alterisio wrote: > 2006/6/6, Robert Cummings <robert@xxxxxxxxxxxxx>: > > > > On Tue, 2006-06-06 at 09:46, Martin Alterisio wrote: > > > 2006/6/6, Robert Cummings <robert@xxxxxxxxxxxxx>: > > > > > > > In C++ they do leave it to the coder, and well, we all know what a > > mess > > > > it can be deciphering overloaded operators in C++ (or maybe we ALL > > > > don't). At any rate, the PHP overlords made a choice, and IMHO the > > best > > > > choice. For such a fringe issue I don't see what the argument is all > > > > about. If you want the functionality you get in C by incrementing a > > > > char, then use the chr() function on an integer. > > > > > > > > > > > You're right about ++ operator not to be considered a math operator, my > > > mistake. What I should have said is that the usual connotation and > > expected > > > behaviour of ++ and the comparison operators is to give iteration > > > capabilities to a certain data type, as used in a for statement. For > > that to > > > happen certain constrains must be true for these operators, one of them > > > being: any < ++any, which is not true for the way these operators behave > > in > > > php. > > > > You must have missed this post: > > > > http://marc.theaimsgroup.com/?l=php-general&m=114945456908350&w=2 > > > > > Yes, I haven't read that post. That algorithm has an error, an overflow on a > signed char, and that's implementation issue not a design issue. Actually it's a design issue. C uses a numeric datatype that is bound by a specific number of bits. It could just have well have been designed with a numeric datatype that had arbitrary length. The design decision was made to keep it close to the machine. However, the point I was making is that dealing with fringe cases is a necessity when you want to ensure your code is robust.
I haven't thought this carefully, you're right to point that is a design issue since compilers and interpreters have to take into account the actual data representation in the design stage. Still, an overload is an known issue and that can be caught easily. If you assume that the ++ and comparison operator can be used with any type of object in a for loop, and they don't follow the expected contrains an iterator shoud have then the problem will be less apparent, as the issue is not considered a misuse but a normal function of the data type.
