2006/6/6, Robert Cummings <[EMAIL PROTECTED]>:
On Tue, 2006-06-06 at 14:31, Martin Alterisio wrote:
> 2006/6/6, Robert Cummings <[EMAIL PROTECTED]>:
> >
> > On Tue, 2006-06-06 at 14:06, Martin Alterisio wrote:
> > > 2006/6/6, Robert Cummings <[EMAIL PROTECTED]>:
> > > >
> > > > > > 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.
