Re: When is "z" != "z" ?

2006/6/4, Rasmus Lerdorf <rasmus@lerdorf.com>:

Martin Alterisio wrote: 2006/6/4, Rasmus Lerdorf <rasmus@lerdorf.com>:

tedd wrote:

Hi gang: Here's your opportunity to pound me again for not knowing the basics

of

php.

I vaguely remember something like this being discussed a while back,

but can't find the reference.

In any event, if one uses -- for ($i="a"; $i<"z"; $i++) { echo($i); } -- it stops at "y" But, if you use -- for ($i="a"; $i<="z"; $i++) { echo($i); } -- it prints considerably more characters after "z" than what one

would

normally expect -- why is that?

Just stopping at "z" would seem to make more sense, wouldn't it?

After

all, when $i = "z" in the first expression, then wouldn't $i be equal to "z" in the second expression and thus halt the operation?

What am I missing here?

It's a bit of a quirk. "z"++ is "aa" and "aa" < "z". I would guess this would loop until until just before "za" which would be "yz".

What? "z"++ < "z" returns true? =S Is there a reason for this? Why aren't they handled like C chars? Because PHP is not C. If you want them handled by their char codes, then do so with chr() calls.

That's cool, but you missed my point, I was just wondering why the ++ operator for string was handled that way. I used the C comparison becuase it's more usual for coders to think as chars in terms of their position in the ASCII table, allowing loops such as the mentioned above. I'm not trying to start another witch hunt, there are enough rantings around for that purpose.

It's a bit like looping through the hexadecimal characters. You would

have the same effect. However instead of being base-16 with 0-9-a-f

you

have base-26 using a-z.

0xF++ would be 0x10 which is greater than 0xF (0xF < 0x10). It's not the same. Sure it is. If you treat 0x10 as a string the same way he is treating these as strings, then 0x10 is going to be smaller than 0xF. The fact is that there is just no right answer for what "z"++ should do. -Rasmus

Still: anything < ++anything should be true, or at least that's what they taught me on abstract data types design, and I think they're right (at least this time)