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

2006/6/6, Robert Cummings <robert@interjinn.com>:

On Tue, 2006-06-06 at 14:31, Martin Alterisio wrote: 2006/6/6, Robert Cummings <robert@interjinn.com>:

On Tue, 2006-06-06 at 14:06, Martin Alterisio wrote:

2006/6/6, Robert Cummings <robert@interjinn.com>:

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.

So there you go, by your own words, knowing the way the system works

and

the edge cases is integral to proper use of the language. Thus when 'z'++ == 'aa' the semantics while not necessarily ubiquitous, fall

under

the language's well defined modus operandi :)

You lost me there. Can you explain it a little bit further? You said:

    "Still, an overload is an known issue and that can be caught
     easily."

It follows that you need information about the overload to handle it. It is a known issue in PHP that incrementing 'z' by 1 produces 'aa' It follows that knowing that 'z' incremented by 1 produces 'aa' can be caught easily. It follows that if it can be caught easily, it can be handled easily. Thus it finally follows your own words:

    "as the issue is not considered a misuse but a normal function
     of the data type"

Normal in PHP is exactly the behaviour that PHP deemed many years ago for it to follow.

Thanks, I got it now. What I meant as "known issue" is that the program is notified of the occurrence of such problem. When the 'z' is incremented into 'aa' you're stepping back in the sequence order but nothing is said or notified in any way. The coder who explicitly wants to use such feature may handle the issue without a problem, but when you work on the basis that you can receive any kind of sequence, range, or iterator you can't know for sure that this happens. Consider this example: function orderedSequence($start, $end) { $orderedSequence = array(); for ($i = $start; $i <= $end; $i++) {

       $orderedSequence[] = $i;

} return $orderedSequence; } Supposedly this function would return an ordered sequence of objects, which implement iteration, between $start and $end. Under the mentioned circumstances the function would fail to return an ordered sequence. Still, this kind of "generic" behaviour it something that isn't useful in PHP, since there isn't operator overloading. Anyway PHP5 has some features that point that generics will be used (correct if i'm wrong here, that's what I thought when I saw iterators in the SPL) and I think that we won't be able to use native operators to create proper iterators on strings with the current functionality assigned to them. Well, my arguments are starting to sound much more like ranting that anything else. Sorry if they weren't appropiate.