A really wacky design decision

Daevid Vincent is surprised that:

$num = 123;
$num = $num++;
print $num; //this prints 123 and not 124 ?!!

To me this is relatively logical. As I understand it, the post-increment operator says "do
something with the variable, and then increment it. The trouble in this case is that we
are doing something irrational; we are copying the number back to itself, and to me it is
reasonably logical (or at least no less illogical than the alternative) to assume that if
we copy it to itself, then increment the original version, the copy will not be
incremented.

However there is one feature of PHP which, to my mind, is really bad design. How many of
you can see anything wrong with the following procedure to search a list of names for a
particular name?

$i = 0; $j = count ($names); while ($i < $j)
{ if ($names[$i] == $target) { break; }
++$i;
}

As long as the names are conventional names, this procedure is probably safe to use.
However if you allow the names to be general alphanumeric strings, it is not reliable. One
of my programs recently broke down in one particular case, and when I eventually isolated
the bug I discovered that it was matching '2260' to '226E1'. (The logic of this is: 226E1
= 226*10^1 = 2260).

I agree that I was well aware of this trap, and that I should not have used a simple
comparison, but it seems to me to be a bizarre design decision to assume that anything
which can be converted to an integer, using any of the available notations, is in fact an
integer, rather than making the default to simply treat it as a string. It is also a trap
that it is very easy to fall into if you start off thinking about simple names, and then
extend (or borrow) the procedure to use more general strings.

And can anyone tell me whether, in the above case, it is sufficient to write simply:
if ((string) $names[$i] == $target),

or should I write:
if ((string) $names[$i] == (string) $target)?

(I decided to play safe and use strcmp ().)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A really wacky design decision

--_75bcf6cc-f029-48bc-8b3a-870cae7d96b0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


And then you discover ===3D

$i =3D 0=3B $j =3D count ($names)=3B while ($i < $j)
{ if ($names[$i] ===3D $target) { break=3B }
++$i=3B
}

.... regards

> To: php-general@lists.php.net
> From: clancy_1@cybec.com.au
> Date: Sat=2C 3 Oct 2009 21:21:00 +1000
> Subject: [PHP] A really wacky design decision
>=20
> Daevid Vincent is surprised that:
>=20
> $num =3D 123=3B
> $num =3D $num++=3B
> print $num=3B //this prints 123 and not 124 ?!!
>=20
> To me this is relatively logical. As I understand it=2C the post-incremen=
t operator says "do
> something with the variable=2C and then increment it. The trouble in this=
case is that we
> are doing something irrational=3B we are copying the number back to itsel=
f=2C and to me it is
> reasonably logical (or at least no less illogical than the alternative) t=
o assume that if
> we copy it to itself=2C then increment the original version=2C the copy w=
ill not be
> incremented.=20
>=20
> However there is one feature of PHP which=2C to my mind=2C is really bad =
design. How many of
> you can see anything wrong with the following procedure to search a list =
of names for a
> particular name?
>=20
> $i =3D 0=3B $j =3D count ($names)=3B while ($i < $j)
> { if ($names[$i] == $target) { break=3B }
> ++$i=3B
> }
>=20
> As long as the names are conventional names=2C this procedure is probably=
safe to use.
> However if you allow the names to be general alphanumeric strings=2C it i=
s not reliable. One
> of my programs recently broke down in one particular case=2C and when I e=
ventually isolated
> the bug I discovered that it was matching '2260' to '226E1'. (The logic o=
f this is: 226E1
> =3D 226*10^1 =3D 2260).
>=20
> I agree that I was well aware of this trap=2C and that I should not have =
used a simple
> comparison=2C but it seems to me to be a bizarre design decision to assum=
e that anything
> which can be converted to an integer=2C using any of the available notati=
ons=2C is in fact an
> integer=2C rather than making the default to simply treat it as a string.=
It is also a trap
> that it is very easy to fall into if you start off thinking about simple =
names=2C and then
> extend (or borrow) the procedure to use more general strings.
>=20
> And can anyone tell me whether=2C in the above case=2C it is sufficient t=
o write simply:=20
> if ((string) $names[$i] == $target),
>=20
> or should I write:=20
> if ((string) $names[$i] == (string) $target)?=20
>=20
> (I decided to play safe and use strcmp ().)
>=20
>=20
> --=20
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe=2C visit: http://www.php.net/unsub.php
>=20
=0A=
____________________________________________________________ _____=0A=
Windows Live: Keep your friends up to date with what you do online.=0A=
http://www.microsoft.com/middleeast/windows/windowslive/see- it-in-action/so=
cial-network-basics.aspx?ocid=3DPID23461::T:WLMTAGL:ON:WL:en -xm:SI_SB_1:092=
010=

--_75bcf6cc-f029-48bc-8b3a-870cae7d96b0_--

Re: A really wacky design decision

u increment after! asigning, so far so good, but for math reasons the
interpreter has to keep in mind the 123 you want to assign before increment
to the same var.

this is absolutely correct what php does here.

$num = ++$num; would print 124
the same like
$num++;

on the other hand this is just bullshit I would release any programmer using
that type of code.

ralph_deffke@yahoo.de

wrote in message
news:8fudc5tc6qvfj4n297kvjlqd3s7sjdkvqb@4ax.com...
> Daevid Vincent is surprised that:
>
> $num = 123;
> $num = $num++;
> print $num; //this prints 123 and not 124 ?!!
>
> To me this is relatively logical. As I understand it, the post-increment
operator says "do
> something with the variable, and then increment it. The trouble in this
case is that we
> are doing something irrational; we are copying the number back to itself,
and to me it is
> reasonably logical (or at least no less illogical than the alternative) to
assume that if
> we copy it to itself, then increment the original version, the copy will
not be
> incremented.
>
> However there is one feature of PHP which, to my mind, is really bad
design. How many of
> you can see anything wrong with the following procedure to search a list
of names for a
> particular name?
>
> $i = 0; $j = count ($names); while ($i < $j)
> { if ($names[$i] == $target) { break; }
> ++$i;
> }
>
> As long as the names are conventional names, this procedure is probably
safe to use.
> However if you allow the names to be general alphanumeric strings, it is
not reliable. One
> of my programs recently broke down in one particular case, and when I
eventually isolated
> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
this is: 226E1
> = 226*10^1 = 2260).
>
> I agree that I was well aware of this trap, and that I should not have
used a simple
> comparison, but it seems to me to be a bizarre design decision to assume
that anything
> which can be converted to an integer, using any of the available
notations, is in fact an
> integer, rather than making the default to simply treat it as a string. It
is also a trap
> that it is very easy to fall into if you start off thinking about simple
names, and then
> extend (or borrow) the procedure to use more general strings.
>
> And can anyone tell me whether, in the above case, it is sufficient to
write simply:
> if ((string) $names[$i] == $target),
>
> or should I write:
> if ((string) $names[$i] == (string) $target)?
>
> (I decided to play safe and use strcmp ().)
>



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: A really wacky design decision

yes for using
$num = $num++;
yes !!!!!!

"Ashley Sheridan" wrote in message
news:1254577641.2385.7.camel@localhost...
> On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> > u increment after! asigning, so far so good, but for math reasons the
> > interpreter has to keep in mind the 123 you want to assign before
increment
> > to the same var.
> >
> > this is absolutely correct what php does here.
> >
> > $num = ++$num; would print 124
> > the same like
> > $num++;
> >
> > on the other hand this is just bullshit I would release any programmer
using
> > that type of code.
> >
> > ralph_deffke@yahoo.de
> >
> > wrote in message
> > news:8fudc5tc6qvfj4n297kvjlqd3s7sjdkvqb@4ax.com...
> > > Daevid Vincent is surprised that:
> > >
> > > $num = 123;
> > > $num = $num++;
> > > print $num; //this prints 123 and not 124 ?!!
> > >
> > > To me this is relatively logical. As I understand it, the
post-increment
> > operator says "do
> > > something with the variable, and then increment it. The trouble in
this
> > case is that we
> > > are doing something irrational; we are copying the number back to
itself,
> > and to me it is
> > > reasonably logical (or at least no less illogical than the
alternative) to
> > assume that if
> > > we copy it to itself, then increment the original version, the copy
will
> > not be
> > > incremented.
> > >
> > > However there is one feature of PHP which, to my mind, is really bad
> > design. How many of
> > > you can see anything wrong with the following procedure to search a
list
> > of names for a
> > > particular name?
> > >
> > > $i = 0; $j = count ($names); while ($i < $j)
> > > { if ($names[$i] == $target) { break; }
> > > ++$i;
> > > }
> > >
> > > As long as the names are conventional names, this procedure is
probably
> > safe to use.
> > > However if you allow the names to be general alphanumeric strings, it
is
> > not reliable. One
> > > of my programs recently broke down in one particular case, and when I
> > eventually isolated
> > > the bug I discovered that it was matching '2260' to '226E1'. (The
logic of
> > this is: 226E1
> > > = 226*10^1 = 2260).
> > >
> > > I agree that I was well aware of this trap, and that I should not have
> > used a simple
> > > comparison, but it seems to me to be a bizarre design decision to
assume
> > that anything
> > > which can be converted to an integer, using any of the available
> > notations, is in fact an
> > > integer, rather than making the default to simply treat it as a
string. It
> > is also a trap
> > > that it is very easy to fall into if you start off thinking about
simple
> > names, and then
> > > extend (or borrow) the procedure to use more general strings.
> > >
> > > And can anyone tell me whether, in the above case, it is sufficient to
> > write simply:
> > > if ((string) $names[$i] == $target),
> > >
> > > or should I write:
> > > if ((string) $names[$i] == (string) $target)?
> > >
> > > (I decided to play safe and use strcmp ().)
> > >
> >
> >
> >
> You'd release a programmer for using the incremental operators for self
> assignation?
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: A really wacky design decision

On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> u increment after! asigning, so far so good, but for math reasons the
> interpreter has to keep in mind the 123 you want to assign before increment
> to the same var.
>
> this is absolutely correct what php does here.
>
> $num = ++$num; would print 124
> the same like
> $num++;
>
> on the other hand this is just bullshit I would release any programmer using
> that type of code.
>
> ralph_deffke@yahoo.de
>
> wrote in message
> news:8fudc5tc6qvfj4n297kvjlqd3s7sjdkvqb@4ax.com...
> > Daevid Vincent is surprised that:
> >
> > $num = 123;
> > $num = $num++;
> > print $num; //this prints 123 and not 124 ?!!
> >
> > To me this is relatively logical. As I understand it, the post-increment
> operator says "do
> > something with the variable, and then increment it. The trouble in this
> case is that we
> > are doing something irrational; we are copying the number back to itself,
> and to me it is
> > reasonably logical (or at least no less illogical than the alternative) to
> assume that if
> > we copy it to itself, then increment the original version, the copy will
> not be
> > incremented.
> >
> > However there is one feature of PHP which, to my mind, is really bad
> design. How many of
> > you can see anything wrong with the following procedure to search a list
> of names for a
> > particular name?
> >
> > $i = 0; $j = count ($names); while ($i < $j)
> > { if ($names[$i] == $target) { break; }
> > ++$i;
> > }
> >
> > As long as the names are conventional names, this procedure is probably
> safe to use.
> > However if you allow the names to be general alphanumeric strings, it is
> not reliable. One
> > of my programs recently broke down in one particular case, and when I
> eventually isolated
> > the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> this is: 226E1
> > = 226*10^1 = 2260).
> >
> > I agree that I was well aware of this trap, and that I should not have
> used a simple
> > comparison, but it seems to me to be a bizarre design decision to assume
> that anything
> > which can be converted to an integer, using any of the available
> notations, is in fact an
> > integer, rather than making the default to simply treat it as a string. It
> is also a trap
> > that it is very easy to fall into if you start off thinking about simple
> names, and then
> > extend (or borrow) the procedure to use more general strings.
> >
> > And can anyone tell me whether, in the above case, it is sufficient to
> write simply:
> > if ((string) $names[$i] == $target),
> >
> > or should I write:
> > if ((string) $names[$i] == (string) $target)?
> >
> > (I decided to play safe and use strcmp ().)
> >
>
>
>
You'd release a programmer for using the incremental operators for self
assignation?

Thanks,
Ash
http://www.ashleysheridan.co.uk




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: A really wacky design decision

--=-h3lVCtZPOcujN71Pw2mp
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Sat, 2009-10-03 at 15:46 +0200, Ralph Deffke wrote:

> yes for using
> $num = $num++;
> yes !!!!!!
>
> "Ashley Sheridan" wrote in message
> news:1254577641.2385.7.camel@localhost...
> > On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> > > u increment after! asigning, so far so good, but for math reasons the
> > > interpreter has to keep in mind the 123 you want to assign before
> increment
> > > to the same var.
> > >
> > > this is absolutely correct what php does here.
> > >
> > > $num = ++$num; would print 124
> > > the same like
> > > $num++;
> > >
> > > on the other hand this is just bullshit I would release any programmer
> using
> > > that type of code.
> > >
> > > ralph_deffke@yahoo.de
> > >
> > > wrote in message
> > > news:8fudc5tc6qvfj4n297kvjlqd3s7sjdkvqb@4ax.com...
> > > > Daevid Vincent is surprised that:
> > > >
> > > > $num = 123;
> > > > $num = $num++;
> > > > print $num; //this prints 123 and not 124 ?!!
> > > >
> > > > To me this is relatively logical. As I understand it, the
> post-increment
> > > operator says "do
> > > > something with the variable, and then increment it. The trouble in
> this
> > > case is that we
> > > > are doing something irrational; we are copying the number back to
> itself,
> > > and to me it is
> > > > reasonably logical (or at least no less illogical than the
> alternative) to
> > > assume that if
> > > > we copy it to itself, then increment the original version, the copy
> will
> > > not be
> > > > incremented.
> > > >
> > > > However there is one feature of PHP which, to my mind, is really bad
> > > design. How many of
> > > > you can see anything wrong with the following procedure to search a
> list
> > > of names for a
> > > > particular name?
> > > >
> > > > $i = 0; $j = count ($names); while ($i < $j)
> > > > { if ($names[$i] == $target) { break; }
> > > > ++$i;
> > > > }
> > > >
> > > > As long as the names are conventional names, this procedure is
> probably
> > > safe to use.
> > > > However if you allow the names to be general alphanumeric strings, it
> is
> > > not reliable. One
> > > > of my programs recently broke down in one particular case, and when I
> > > eventually isolated
> > > > the bug I discovered that it was matching '2260' to '226E1'. (The
> logic of
> > > this is: 226E1
> > > > = 226*10^1 = 2260).
> > > >
> > > > I agree that I was well aware of this trap, and that I should not have
> > > used a simple
> > > > comparison, but it seems to me to be a bizarre design decision to
> assume
> > > that anything
> > > > which can be converted to an integer, using any of the available
> > > notations, is in fact an
> > > > integer, rather than making the default to simply treat it as a
> string. It
> > > is also a trap
> > > > that it is very easy to fall into if you start off thinking about
> simple
> > > names, and then
> > > > extend (or borrow) the procedure to use more general strings.
> > > >
> > > > And can anyone tell me whether, in the above case, it is sufficient to
> > > write simply:
> > > > if ((string) $names[$i] == $target),
> > > >
> > > > or should I write:
> > > > if ((string) $names[$i] == (string) $target)?
> > > >
> > > > (I decided to play safe and use strcmp ().)
> > > >
> > >
> > >
> > >
> > You'd release a programmer for using the incremental operators for self
> > assignation?
> >
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> >
> >
> >
>
>
>

To be honest, of all the programming sins, this is not one to fire
someone for. Have a look at the daily wtf and you'll see what i mean!

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-h3lVCtZPOcujN71Pw2mp--

Re: Re: A really wacky design decision

this is a clear sign that somebody is on a sin TRAIL, I would not even spend
the time on what sin collections this guy got

"Ashley Sheridan" wrote in message
news:1254577986.2385.8.camel@localhost...
> On Sat, 2009-10-03 at 15:46 +0200, Ralph Deffke wrote:
>
> > yes for using
> > $num = $num++;
> > yes !!!!!!
> >
> > "Ashley Sheridan" wrote in message
> > news:1254577641.2385.7.camel@localhost...
> > > On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote:
> > > > u increment after! asigning, so far so good, but for math reasons
the
> > > > interpreter has to keep in mind the 123 you want to assign before
> > increment
> > > > to the same var.
> > > >
> > > > this is absolutely correct what php does here.
> > > >
> > > > $num = ++$num; would print 124
> > > > the same like
> > > > $num++;
> > > >
> > > > on the other hand this is just bullshit I would release any
programmer
> > using
> > > > that type of code.
> > > >
> > > > ralph_deffke@yahoo.de
> > > >
> > > > wrote in message
> > > > news:8fudc5tc6qvfj4n297kvjlqd3s7sjdkvqb@4ax.com...
> > > > > Daevid Vincent is surprised that:
> > > > >
> > > > > $num = 123;
> > > > > $num = $num++;
> > > > > print $num; //this prints 123 and not 124 ?!!
> > > > >
> > > > > To me this is relatively logical. As I understand it, the
> > post-increment
> > > > operator says "do
> > > > > something with the variable, and then increment it. The trouble in
> > this
> > > > case is that we
> > > > > are doing something irrational; we are copying the number back to
> > itself,
> > > > and to me it is
> > > > > reasonably logical (or at least no less illogical than the
> > alternative) to
> > > > assume that if
> > > > > we copy it to itself, then increment the original version, the
copy
> > will
> > > > not be
> > > > > incremented.
> > > > >
> > > > > However there is one feature of PHP which, to my mind, is really
bad
> > > > design. How many of
> > > > > you can see anything wrong with the following procedure to search
a
> > list
> > > > of names for a
> > > > > particular name?
> > > > >
> > > > > $i = 0; $j = count ($names); while ($i < $j)
> > > > > { if ($names[$i] == $target) { break; }
> > > > > ++$i;
> > > > > }
> > > > >
> > > > > As long as the names are conventional names, this procedure is
> > probably
> > > > safe to use.
> > > > > However if you allow the names to be general alphanumeric strings,
it
> > is
> > > > not reliable. One
> > > > > of my programs recently broke down in one particular case, and
when I
> > > > eventually isolated
> > > > > the bug I discovered that it was matching '2260' to '226E1'. (The
> > logic of
> > > > this is: 226E1
> > > > > = 226*10^1 = 2260).
> > > > >
> > > > > I agree that I was well aware of this trap, and that I should not
have
> > > > used a simple
> > > > > comparison, but it seems to me to be a bizarre design decision to
> > assume
> > > > that anything
> > > > > which can be converted to an integer, using any of the available
> > > > notations, is in fact an
> > > > > integer, rather than making the default to simply treat it as a
> > string. It
> > > > is also a trap
> > > > > that it is very easy to fall into if you start off thinking about
> > simple
> > > > names, and then
> > > > > extend (or borrow) the procedure to use more general strings.
> > > > >
> > > > > And can anyone tell me whether, in the above case, it is
sufficient to
> > > > write simply:
> > > > > if ((string) $names[$i] == $target),
> > > > >
> > > > > or should I write:
> > > > > if ((string) $names[$i] == (string) $target)?
> > > > >
> > > > > (I decided to play safe and use strcmp ().)
> > > > >
> > > >
> > > >
> > > >
> > > You'd release a programmer for using the incremental operators for
self
> > > assignation?
> > >
> > > Thanks,
> > > Ash
> > > http://www.ashleysheridan.co.uk
> > >
> > >
> > >
> >
> >
> >
>
> To be honest, of all the programming sins, this is not one to fire
> someone for. Have a look at the daily wtf and you'll see what i mean!
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A really wacky design decision

At 9:21 PM +1000 10/3/09, clancy_1@cybec.com.au wrote:
>Daevid Vincent is surprised that:
>
>$num = 123;
>$num = $num++;
>print $num; //this prints 123 and not 124 ?!!

I can understand why someone might think this is not correct, but
they need to understand what is happening and why the above second
assignment statement is in bad form (IMO).

The first statement assigns 123 to $num. Everyone is OK with that.
The next statement assigns 123 to $num, but then tries to increment
$num, but doesn't because the assignment overrides the ++ operator --
this is bad form (IMO).

Now, if you change the syntax to this:

$num = 123;
$num = ++num;
print $num; //this prints 124

The first statement assigns 123 to $num.
The next statement adds 1 to $num and then assigns 124 to $num, but
it's still not the best form because you can do the same thing with:

++$num;

OR

$num++;

It's usually easier to understand if one doesn't compound statements
with ++ operator.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: A really wacky design decision

On 10/3/09 9:53 AM, "Ralph Deffke" wrote:

> this is a clear sign that somebody is on a sin TRAIL, I would not even spend
> the time on what sin collections this guy got

i see it more as ignorance than sin.

to misunderstand the difference between $n++ and ++$n is a beginner error.

as k&r made very clear with their sequences of lessons in the original book,
without actually saying so, becoming "an experienced programming" is like
becoming a zen master. it is a progression to sophistication, the exemplars
of which can be found here:

http://www1.us.ioccc.org/years-spoiler.html

i particularly recommend herrmann2 from 2001. masterful and dumbfounding.
read the .hint file.




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A really wacky design decision

On 10/3/09 7:21 AM, "clancy_1@cybec.com.au" wrote:

> However there is one feature of PHP which, to my mind, is really bad design.
> How many of
> you can see anything wrong with the following procedure to search a list of
> names for a
> particular name?
>
> $i = 0; $j = count ($names); while ($i < $j)
> { if ($names[$i] == $target) { break; }
> ++$i;
> }
>
> As long as the names are conventional names, this procedure is probably safe
> to use.
> However if you allow the names to be general alphanumeric strings, it is not
> reliable. One
> of my programs recently broke down in one particular case, and when I
> eventually isolated
> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> this is: 226E1
> = 226*10^1 = 2260).
>
> I agree that I was well aware of this trap, and that I should not have used a
> simple
> comparison, but it seems to me to be a bizarre design decision to assume that
> anything
> which can be converted to an integer, using any of the available notations, is
> in fact an
> integer, rather than making the default to simply treat it as a string.

this is odd.

i might think it ok for (2260 == '226E1') to be true since php would be
doing type juggling in a logical left-to-right manner: we start with an
integer 2260, next is the juggling comparison operator, then a string, so it
might reasonably try to convert the string to an integer and then compare.

but with ('2260' == '226E1'), where both lhs and rhs are already of the same
time, it seems elliptical, to say the least, that php should search the
types to which it can convert the strings looking for one in which they are
equal.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A really wacky design decision

--=-6JONZU0PG8yzu0ibnAIb
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:

> On 10/3/09 7:21 AM, "clancy_1@cybec.com.au" wrote:
>
> > However there is one feature of PHP which, to my mind, is really bad design.
> > How many of
> > you can see anything wrong with the following procedure to search a list of
> > names for a
> > particular name?
> >
> > $i = 0; $j = count ($names); while ($i < $j)
> > { if ($names[$i] == $target) { break; }
> > ++$i;
> > }
> >
> > As long as the names are conventional names, this procedure is probably safe
> > to use.
> > However if you allow the names to be general alphanumeric strings, it is not
> > reliable. One
> > of my programs recently broke down in one particular case, and when I
> > eventually isolated
> > the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> > this is: 226E1
> > = 226*10^1 = 2260).
> >
> > I agree that I was well aware of this trap, and that I should not have used a
> > simple
> > comparison, but it seems to me to be a bizarre design decision to assume that
> > anything
> > which can be converted to an integer, using any of the available notations, is
> > in fact an
> > integer, rather than making the default to simply treat it as a string.
>
> this is odd.
>
> i might think it ok for (2260 == '226E1') to be true since php would be
> doing type juggling in a logical left-to-right manner: we start with an
> integer 2260, next is the juggling comparison operator, then a string, so it
> might reasonably try to convert the string to an integer and then compare.
>
> but with ('2260' == '226E1'), where both lhs and rhs are already of the same
> time, it seems elliptical, to say the least, that php should search the
> types to which it can convert the strings looking for one in which they are
> equal.
>
>
>


I don't know what you mean by elliptical, but I'd expect and certainly
hope that PHP wouldn't try to convert both strings to something which
would mean they had the same value. Also, afaik, if the variables types
are exactly the same, PHP won't try to convert either of them for a
comparison

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-6JONZU0PG8yzu0ibnAIb--

Re: A really wacky design decision

tedd wrote:
> At 9:21 PM +1000 10/3/09, clancy_1@cybec.com.au wrote:
>> Daevid Vincent is surprised that:
>>
>> $num = 123;
>> $num = $num++;
>> print $num; //this prints 123 and not 124 ?!!
>
> I can understand why someone might think this is not correct, but
> they need to understand what is happening and why the above second
> assignment statement is in bad form (IMO).
>
> The first statement assigns 123 to $num. Everyone is OK with that.
> The next statement assigns 123 to $num, but then tries to increment
> $num, but doesn't because the assignment overrides the ++ operator --
> this is bad form (IMO).

While I absolutely agree that it is bad form, I think you got the actual
flow wrong. I think the $num++ copies the current value of $num, then
increments $num to 124, then the previously copied value is returned at
which point the assignment operator receives it and then overwrites the
124 with the copy of 123.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A really wacky design decision

On 10/3/09 12:25 PM, "Ashley Sheridan" wrote:

> On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
>
>> On 10/3/09 7:21 AM, "clancy_1@cybec.com.au" wrote:
>>
>>> However there is one feature of PHP which, to my mind, is really bad design.
>>> How many of
>>> you can see anything wrong with the following procedure to search a list of
>>> names for a
>>> particular name?
>>>
>>> $i = 0; $j = count ($names); while ($i < $j)
>>> { if ($names[$i] == $target) { break; }
>>> ++$i;
>>> }
>>>
>>> As long as the names are conventional names, this procedure is probably safe
>>> to use.
>>> However if you allow the names to be general alphanumeric strings, it is not
>>> reliable. One
>>> of my programs recently broke down in one particular case, and when I
>>> eventually isolated
>>> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
>>> this is: 226E1
>>> = 226*10^1 = 2260).
>>>
>>> I agree that I was well aware of this trap, and that I should not have used
>>> a
>>> simple
>>> comparison, but it seems to me to be a bizarre design decision to assume
>>> that
>>> anything
>>> which can be converted to an integer, using any of the available notations,
>>> is
>>> in fact an
>>> integer, rather than making the default to simply treat it as a string.
>>
>> this is odd.
>>
>> i might think it ok for (2260 == '226E1') to be true since php would be
>> doing type juggling in a logical left-to-right manner: we start with an
>> integer 2260, next is the juggling comparison operator, then a string, so it
>> might reasonably try to convert the string to an integer and then compare.
>>
>> but with ('2260' == '226E1'), where both lhs and rhs are already of the same
>> time, it seems elliptical, to say the least, that php should search the
>> types to which it can convert the strings looking for one in which they are
>> equal.
>>
>
> I don't know what you mean by elliptical, but I'd expect and certainly
> hope that PHP wouldn't try to convert both strings to something which
> would mean they had the same value. Also, afaik, if the variables types
> are exactly the same, PHP won't try to convert either of them for a
> comparison

i once had such hope too.

$ php -r "var_dump('2260' == '226E1');"
bool(true)


elliptical: tending to be ambiguous, cryptic, or obscure: an elliptical
prose that is difficult to translate.
(http://dictionary.reference.com/browse/elliptical)



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A really wacky design decision

Tom Worster wrote:
> On 10/3/09 12:25 PM, "Ashley Sheridan" wrote:
>
>> On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
>>
>>> On 10/3/09 7:21 AM, "clancy_1@cybec.com.au" wrote:
>>>
>>>> However there is one feature of PHP which, to my mind, is really bad design.
>>>> How many of
>>>> you can see anything wrong with the following procedure to search a list of
>>>> names for a
>>>> particular name?
>>>>
>>>> $i = 0; $j = count ($names); while ($i < $j)
>>>> { if ($names[$i] == $target) { break; }
>>>> ++$i;
>>>> }
>>>>
>>>> As long as the names are conventional names, this procedure is probably safe
>>>> to use.
>>>> However if you allow the names to be general alphanumeric strings, it is not
>>>> reliable. One
>>>> of my programs recently broke down in one particular case, and when I
>>>> eventually isolated
>>>> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
>>>> this is: 226E1
>>>> = 226*10^1 = 2260).
>>>>
>>>> I agree that I was well aware of this trap, and that I should not have used
>>>> a
>>>> simple
>>>> comparison, but it seems to me to be a bizarre design decision to assume
>>>> that
>>>> anything
>>>> which can be converted to an integer, using any of the available notations,
>>>> is
>>>> in fact an
>>>> integer, rather than making the default to simply treat it as a string.
>>> this is odd.
>>>
>>> i might think it ok for (2260 == '226E1') to be true since php would be
>>> doing type juggling in a logical left-to-right manner: we start with an
>>> integer 2260, next is the juggling comparison operator, then a string, so it
>>> might reasonably try to convert the string to an integer and then compare.
>>>
>>> but with ('2260' == '226E1'), where both lhs and rhs are already of the same
>>> time, it seems elliptical, to say the least, that php should search the
>>> types to which it can convert the strings looking for one in which they are
>>> equal.
>>>
>> I don't know what you mean by elliptical, but I'd expect and certainly
>> hope that PHP wouldn't try to convert both strings to something which
>> would mean they had the same value. Also, afaik, if the variables types
>> are exactly the same, PHP won't try to convert either of them for a
>> comparison
>
> i once had such hope too.
>
> $ php -r "var_dump('2260' == '226E1');"
> bool(true)

Numeric strings are special :)

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A really wacky design decision

--_248c7194-5e8e-4901-815d-dbd6e56c85d5_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


if we compare via "==" there is an implicit cast to the most primitive =
form.

These are all true=2C and all have a reason=2C and make sense:

// (int)'abc' is 0
var_dump('abc' == 0)=3B

// 'abc' is not an empty string
var_dump('abc' == true)=3B

// 2 is not 0=2C which would be casted into false=2C so it's true
var_dump(2 == true)=3B

A common error is usually in MySQL queries without explicit cast comparing =
strings to numbers as well ... this is bad=2C specially because every progr=
ammer should have at least low level programming languages basis ... that c=
an only help to better understand today high level programming languages.

The reason we use=2C love=2C hate PHP as loose type scripting language does=
not mean we should avoid to understand how php works internally (C)

Loose type is only manifested to the developer=2C but it will never be behi=
nd (still C)

If you use APD or you think about the low level logic behind comparing stri=
ng=2C num and bool you'll probably forget the "==" operator and you'll =
never miss again the "===3D" one ... then you'll start to explicit cast=
everything=2C when necessary=2C to have all your code truly under control=
=2C and that is the moment you'll realize PHP is not for you 'cause you are=
forcing a typeless language to be strict ... and then you'll start to deve=
lop via C=2C Python=2C Java=2C or C#=2C ending up with JavaScript on server=
side 'cause is the only scripting language=2C without pretending classic O=
OP=2C that makes sense ... (sorry for the last part of this reply=2C that's=
just what happened to me)

Regards
=0A=
____________________________________________________________ _____=0A=
Windows Live: Friends get your Flickr=2C Yelp=2C and Digg updates when they=
e-mail you.=0A=
http://www.microsoft.com/middleeast/windows/windowslive/see- it-in-action/so=
cial-network-basics.aspx?ocid=3DPID23461::T:WLMTAGL:ON:WL:en -xm:SI_SB_3:092=
010=

--_248c7194-5e8e-4901-815d-dbd6e56c85d5_--

Re: A really wacky design decision

Andrea Giammarchi wrote:
> If you use APD or you think about the low level logic behind comparing string,
> num and bool you'll probably forget the "==" operator and you'll
never miss
> again the "===" one ... then you'll start to explicit cast
everything, when
> necessary, to have all your code truly under control, and that is the
moment
> you'll realize PHP is not for you 'cause you are forcing a typeless
language
> to be strict ... and then you'll start to develop via C, Python,
Java, or C#,

PHP allows you to do either. If I find myself being more strict in no
way does that mean I'll suddenly jump to another language. It just means
I have a bit of code that requires a bit more strictness. Should I
suddenly switch languages because when using the strpos() function I
must use the === operator to check for existence of a substring? Utter
silliness IMHO.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A really wacky design decision

--_935fae50-e5f2-4202-81b0-8d5047944982_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


You introduced the word "suddenly"=2C it's about 10 years I develop in PHP

Regards


> PHP allows you to do either. If I find myself being more strict in no=20
> way does that mean I'll suddenly jump to another language. It just means=
=20
> I have a bit of code that requires a bit more strictness. Should I=20
> suddenly switch languages because when using the strpos() function I=20
> must use the ===3D operator to check for existence of a substring? Ut=
ter=20
> silliness IMHO.
>=20
> Cheers=2C
> Rob.
> --=20
> http://www.interjinn.com
> Application and Templating Framework for PHP
=0A=
____________________________________________________________ _____=0A=
Keep your friends updated=97even when you=92re not signed in.=0A=
http://www.microsoft.com/middleeast/windows/windowslive/see- it-in-action/so=
cial-network-basics.aspx?ocid=3DPID23461::T:WLMTAGL:ON:WL:en -xm:SI_SB_5:092=
010=

--_935fae50-e5f2-4202-81b0-8d5047944982_--

Re: A really wacky design decision

At 1:37 PM -0400 10/3/09, Robert Cummings wrote:
>tedd wrote:
>>At 9:21 PM +1000 10/3/09, clancy_1@cybec.com.au wrote:
>>>Daevid Vincent is surprised that:
>>>
>>>$num = 123;
>>>$num = $num++;
>>>print $num; //this prints 123 and not 124 ?!!
>>
>>I can understand why someone might think this is not correct, but
>>they need to understand what is happening and why the above second
>>assignment statement is in bad form (IMO).
>>
>>The first statement assigns 123 to $num. Everyone is OK with that.
>>The next statement assigns 123 to $num, but then tries to increment
>>$num, but doesn't because the assignment overrides the ++ operator
>>-- this is bad form (IMO).
>
>While I absolutely agree that it is bad form, I think you got the
>actual flow wrong. I think the $num++ copies the current value of
>$num, then increments $num to 124, then the previously copied value
>is returned at which point the assignment operator receives it and
>then overwrites the 124 with the copy of 123.
>
>Cheers,
>Rob.
>--

Rob:

That could very well be -- I really don't know the flow. That was my
best guess and what made sense to me.

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: A really wacky design decision

On Sun, 4 Oct 2009 14:52:36 +0200, an_red@hotmail.com (Andrea Giammarchi) wrote:

>
>
>
>> $a = 2260; $b = 226e1; $c = 2.26e3; $d = 2260.0;
>>
>> $a==$b==$c==$d,
>>
>> and
>> $b===$c===$d
>
>$b , $c, and $d are the same indeed ... they represent the floating point 2260.0 in I think every language ... it's like saying that 1.0 is not 1.0000 ... both floating point numbers, so I don't get your problem ...

IF they are actually floating point numbers. My problem is that I'm working with values
which are strings, but which sometimes look like either integers or floating point
numbers. And I apologise for falsely contradicting your previous message; I realised
subsequently that I had forgotten to specify the variables as strings in my test. Thus, if
I write:

$a = 2260; $b = '2260'; the exact comparison returns 'false'.

The same applies to all the cases I had been complaining about, and the exact comparison
does indeed work as you stated. This piece of carelessness arose because my data is
represented in the simple form, eg:

A;e;21TH;AP;;;;Musical education;090701

but is implicitly converted into strings when it is entered.

(And I tend to be wary of determining the rules experimentally. I learned my programming
on CDC3200 Fortran fortysomething years ago. Manuals were brief and textbooks
non-existent, so whenever we were not sure of something we would try it. Unfortunately the
Fortran had some very strange design features, which we learnt about when our employer
upgraded to a CDC 6600. This used a much more standard Fortran, and many of the tricks we
had discovered no longer worked.)


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: A really wacky design decision

--_3aabf359-c70d-44a1-8950-3ceba87bdb75_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



> but is implicitly converted into strings when it is entered.

use floatVal($str1) ===3D floatVal($str2) then ... I honestly cannot sp=
ot any problem in what you wanna do=2C I can just spot an error in the root=
of the process: threat strings as numbers=2C comparing potatoes and tomato=
es ...=20

there are filters used for validation as well in php=2C maybe those filters=
=2C hopefully faster than PCRE=2C could help you to understand if a string =
is a number=2C or not.

Regards
=0A=
____________________________________________________________ _____=0A=
Keep your friends updated=97even when you=92re not signed in.=0A=
http://www.microsoft.com/middleeast/windows/windowslive/see- it-in-action/so=
cial-network-basics.aspx?ocid=3DPID23461::T:WLMTAGL:ON:WL:en -xm:SI_SB_5:092=
010=

--_3aabf359-c70d-44a1-8950-3ceba87bdb75_--