Hello internals,
I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling
On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks wrote:
> Hello internals,
>
> I should voice my opinion that such things like comparing two strings
> starting with numbers and that they resolve to actual integer/float for
> comparation is bad, really bad. That just defies the logic and yealds
> ab
On Mon, 07 May 2012 10:31:00 +0200, Kris Craig
wrote:
That being said, I agree that this *definitely* should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over
10 years and I was never aware of this bizarre behavior, either). I
don't
know the history
On Mon, May 7, 2012 at 10:31 AM, Kris Craig wrote:
> On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks >wrote:
>
> > Hello internals,
> >
> > I should voice my opinion that such things like comparing two strings
> > starting with numbers and that they resolve to actual integer/float for
> > compar
On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes wrote:
> On Mon, 07 May 2012 10:31:00 +0200, Kris Craig
> wrote:
>
> That being said, I agree that this *definitely* should be fixed if the
>>
>> examples cited are indeed accurate (I've been working with PHP for over
>> 10 years and I was never awar
On Mon, May 7, 2012 at 11:22 AM, Kris Craig wrote:
> On Mon, May 7, 2012 at 1:46 AM, Gustavo Lopes >wrote:
>
> > On Mon, 07 May 2012 10:31:00 +0200, Kris Craig
> > wrote:
> >
> > That being said, I agree that this *definitely* should be fixed if the
> >>
> >> examples cited are indeed accurate
>
> I agree with Rasmus (and others) on this one
> (http://www.mail-archive.com/internals@lists.php.net/msg57949.html), type
> numeric conversion on strings on both sides should only happen if both
> strings can be represented as numbers without losing data/precision.
> if one or both of the two si
Easy - you see == everywhere and === is used rarely, in docs you see it in
some places like strpos(). This is one thing that has to be communicated
through every channel available (including docs) with clear examples that
show why it should be used instead of ==.
Take me for example, I never had an
On 05/07/2012 09:28 AM, Arvids Godjuks wrote:
> Hello internals,
>
> I should voice my opinion that such things like comparing two strings
> starting with numbers and that they resolve to actual integer/float for
> comparation is bad, really bad. That just defies the logic and yealds
> absolutly u
On 05/07/2012 05:32 AM, Tjerk Anne Meesters wrote:
> Validated or not, why would type juggling even come into the picture
> if both variables are of the same type?
For the simple reason that web forms return all input as strings, even
if the input is actually meant to be numeric
Many PHP databas
This has been changed to the more traditional way.
I've moved on and am using _isset and _unset for the moment, but I'll clone my
branch with what I need to accomplish and post it here tonight.
-Original Message-
From: Felipe Pena [mailto:felipe...@gmail.com]
Sent: Saturday, May 05, 2
> On 05/07/2012 05:32 AM, Tjerk Anne Meesters wrote:
>
>> Validated or not, why would type juggling even come into the picture
>> if both variables are of the same type?
>
> For the simple reason that web forms return all input as strings, even
> if the input is actually meant to be numeric
>
> Man
Alright, I'm new to git but I believe I have a branch off my fork which
demonstrates the issue.
https://github.com/cpriest/php-src/tree/isset-unset-issue
This branch also features just code necessary to produce the results, if you
search in zend_compile.h for ISSUE-ISSET-LANGUAGE-PARSER you'll
On Mon, May 7, 2012 at 9:16 PM, Clint Priest wrote:
> Alright, I'm new to git but I believe I have a branch off my fork which
> demonstrates the issue.
>
> https://github.com/cpriest/php-src/tree/isset-unset-issue
>
> This branch also features just code necessary to produce the results, if you
>
That makes complete sense, it is indeed a LONG type that's getting to that
point, thank you!
> -Original Message-
> From: Nikita Popov [mailto:nikita@googlemail.com]
> Sent: Monday, May 07, 2012 2:27 PM
> To: Clint Priest
> Cc: Etienne Kneuss; Felipe Pena (felipe...@gmail.com); inter
I was very surprised when I came across the == issue sometime ago. IMO
strings should be compared as strings. They should never be converted to
integer.
1=="1" // always convert the number value to a string and then
compare it
"foo" == 0// should return false
"123abc" == "123nth" /
While it's not the prettiest of side effects in php, I don't agree it should be
"fixed"
On top of a massive BC break, it's not as if the results are inconsistent.
Learning php means learning how type juggling works.
At most, I'd remove the part that truncates numeric strings like "123abc" and
> At most, I'd remove the part that truncates numeric strings like
> "123abc" and always convert them to 0, because that's almost *never*
> an intended effect.
I too find it hard to think of the situation in which data must be
stored, even in a temporary form, as "123abc" but is meant to be
equiv
18 matches
Mail list logo
