RE: [PHP] A really wacky design decision
but is implicitly converted into strings when it is entered. use floatVal($str1) === floatVal($str2) then ... I honestly cannot spot any problem in what you wanna do, I can just spot an error in the root of the process: threat strings as numbers, comparing potatoes and tomatoes ... there are filters used for validation as well in php, maybe those filters, hopefully faster than PCRE, could help you to understand if a string is a number, or not. Regards _ Keep your friends updated—even when you’re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
Re: [PHP] A really wacky design decision
On Sun, 4 Oct 2009 14:52:36 +0200, an_...@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. ... 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;APMusical 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: [PHP] A really wacky design decision
I am well aware of the === operator, but I had an uneasy feeling that there was
still a
trap. However when I tried it it worked, so I was going to thank you for your
suggestion,
though I find the concept of having separate 'sort of equal' and 'truly equal'
operators
decidedly distasteful, but then I discovered that if you have:
$a = 2260; $b = 226e1; $c = 2.26e3; $d = 2260.0;
$a==$b==$c==$d,
and
$b===$c===$d
Granted $c $d are less likely to be encountered by accident, but if I want to
be certain
the two strings match I will have to stick to the (string) cast or use strcmp.
Perhaps we
need a 'really truly equal' operator !
Clancy
And then you discover ===
$i = 0; $j = count ($names); while ($i $j)
{ if ($names[$i] === $target) { break; }
++$i;
}
... regards
To: php-general@lists.php.net
From: clanc...@cybec.com.au
Date: Sat, 3 Oct 2009 21:21:00 +1000
Subject: [PHP] 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
_
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A really wacky design decision
On Sat, 03 Oct 2009 11:57:36 -0400, f...@thefsb.org (Tom Worster) wrote:
On 10/3/09 7:21 AM, clanc...@cybec.com.au clanc...@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.
The order doesn't matter; 2260 == 226e1, and 226e1==2260.
It looks as if (for comparisons) PHP's order of preference is Integer Real
?? ??
String.
If you use '==' it will try to convert everything to integer, but if you use
'===' it will
try to render them in some standard format (so that 226e1 === 2.26e3), but will
not
convert real to integer. Despite which if you print them without specifying a
format it
will print them all as 2260.
All very messy!
Clancy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] A really wacky design decision
$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. ... both floating point numbers, so I don't get your problem ... _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
RE: [PHP] A really wacky design decision
All very messy! there is nothing messy, the logic is well defined and for a loose type language it's absolutely normal behavior. Regards _ Keep your friends updated—even when you’re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
Re: [PHP] A really wacky design decision
On 10/4/09 6:36 AM, clanc...@cybec.com.au clanc...@cybec.com.au wrote:
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.
The order doesn't matter; 2260 == 226e1, and 226e1==2260.
in those two cases, all four operands are integer literals. no juggling is
involved.
and i would have expected the same for ('2260' == '226e1') and ('226e1' ==
'2260') since all operands are string literals and i'd be wrong. (evidently
i'm not alone in making this mistake.)
i get confused reading the manual:
http://www.php.net/manual/en/language.types.type-juggling.php
says that the context determines if the expression is converted. the example
being the + operator. by definition, it's operands are numeric contexts so
strings are converted. fair enough.
now what about the == operator?
http://www.php.net/manual/en/language.operators.comparison.php
that page contradicts the previous one because it says that, when an operand
is a string, the determination to convert an operand depends not on the
context but on the specific data _of_ the operand.
i think robert captured the essence of this confusion nicely with:
On 10/3/09 1:53 PM, Robert Cummings rob...@interjinn.com wrote:
Numeric strings are special :)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] A really wacky design decision
And then you discover ===
$i = 0; $j = count ($names); while ($i $j)
{ if ($names[$i] === $target) { break; }
++$i;
}
... regards
To: php-general@lists.php.net
From: clanc...@cybec.com.au
Date: Sat, 3 Oct 2009 21:21:00 +1000
Subject: [PHP] 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
_
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
Re: [PHP] A really wacky design decision
At 9:21 PM +1000 10/3/09, clanc...@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: [PHP] A really wacky design decision
On 10/3/09 7:21 AM, clanc...@cybec.com.au clanc...@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: [PHP] A really wacky design decision
On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
On 10/3/09 7:21 AM, clanc...@cybec.com.au clanc...@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
Re: [PHP] A really wacky design decision
tedd wrote: At 9:21 PM +1000 10/3/09, clanc...@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: [PHP] A really wacky design decision
On 10/3/09 12:25 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote:
On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
On 10/3/09 7:21 AM, clanc...@cybec.com.au clanc...@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: [PHP] A really wacky design decision
Tom Worster wrote:
On 10/3/09 12:25 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote:
On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
On 10/3/09 7:21 AM, clanc...@cybec.com.au clanc...@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: [PHP] A really wacky design decision
if we compare via == there is an implicit cast to the most primitive form.
These are all true, and all have a reason, and make sense:
// (int)'abc' is 0
var_dump('abc' == 0);
// 'abc' is not an empty string
var_dump('abc' == true);
// 2 is not 0, which would be casted into false, so it's true
var_dump(2 == true);
A common error is usually in MySQL queries without explicit cast comparing
strings to numbers as well ... this is bad, specially because every programmer
should have at least low level programming languages basis ... that can only
help to better understand today high level programming languages.
The reason we use, love, 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, but it will never be behind
(still C)
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#,
ending up with JavaScript on server side 'cause is the only scripting language,
without pretending classic OOP, that makes sense ... (sorry for the last part
of this reply, that's just what happened to me)
Regards
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010
Re: [PHP] 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: [PHP] A really wacky design decision
You introduced the word suddenly, 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 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 _ Keep your friends updated—even when you’re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
Re: [PHP] 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, clanc...@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
