[PHP-DEV] == Comparison type juggling
I'm sure this has probably been covered here in the past, but I've been unable to find a good way to search for it, so I'll just ask. if( '2011020402421730' === '20110204024217300264' ) echo 'BAD'; else echo 'GOOD'; results in GOOD being echoed. However, if( '2011020402421730' == '20110204024217300264' ) echo 'BAD'; else echo 'GOOD'; results in BAD being echoed. We guessed that probably the strings were both being converted to ints for the comparison (even on a 64-bit platform 20-digit ints are too large), and indeed the documentation says that If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. My questions are: 1) What is the advantage to converting both strings to ints to compare them? We have code that compares values for updating in a database, and in this case we were explicitly treating the data as strings, but don't always do so. It was very non-obvious to us that comparing a string-type to a string-type results in the type translation when using ==. It seems counter-productive to have to do: if( (string) $a === (string) $b ) . in every circumstance where $a and $b are be strings representing very large integers. To be clear, I'm referring specifically to circumstances where the type of the objects on both sides of the == comparison are the same. (Maybe int-strings should be a special case, or perhaps this should apply to any object type?) 2) The documentation (http://www.php.net/manual/en/language.operators.comparison.php) only mentions type juggling for ==, !=, and , but not greater-than or less-than comparisons. Does this happen with those as well? (If so, I think it could be helpful to have the documentation show this.) 3) If the expected/desired behavior is really to have both strings converted to ints to do the comparison, it would make sense to me to have a loss of precision warning- or something to that effect- when the int exceeds the limits of PHP_INT_SIZE-byte ints. However, other than backward compatibility, I have been unable to think of a reason why two strings containing string-representations of ints should be converted for the comparison-- especially with ==. Thanks for your time everybody, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] == Comparison type juggling
On Fri, Apr 22, 2011 at 10:27:33AM -0400, Matt Pelmear wrote: My questions are: 1) What is the advantage to converting both strings to ints to compare them? It makes things easy for working on what comes back from a form (in $_POST/...). It is a nice feature, and works well *most* of the time. I do wish that the Perl way of doing it had been used, ie: == numeric compare eq text compare It solves many problems at the cost of a little more developer clue. I suppose that the proper way is to use as you say: if( (string) $a === (string) $b ) . or strcmp() -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] == Comparison type juggling
or strcmp() yeah, strcmp is your friend there. Brian. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Unmaintained SAPIs
Hi, we have quite a few SAPIs where I expect that nobody looked at them for years. Anybody objects from dropping them from trunk? This brings less stuff to document and less confusion for users. I suggest dropping: aolserver caudium continuity milter phttpd pi3web roxen thttpd tux webjames I'm not sure about: apache_hooks apache2filter isapi (is FastCGI now preferred on Win?) That leaves: apache apache2handler cgi cli embed fpm litespeed nsapi johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHPUnit segfault
Hi, I'm a bit lost here. Don't know where to go, since PHP 5.3.6 i'm getting random segfaults using PHPUnit. Xdebug disabledPHPUnit 3.5.13CentOS 5.1Linux 2.6.18-028stab070.5 #1 SMP Fri Sep 17 15:37:23 MSD 2010 i686 i686 i386 GNU/LinuxCentOS release 5.6 (Final)Apache 2.2.17 I just want to know if i'm on the right place and which tools may i use to debug this.By random segfaults i mean some times a testsuite completes without any trouble,and some other times it fails somwhere in the middle, Regards, Andras
RE: [PHP-DEV] PHPUnit segfault
Hi,Great news, this issue is only happening in PHP 5.3.6. I just compiled 5.3.5 and everything is fine. Please let me know what i can do to help you with this,Andras From: lgand...@hotmail.com To: internals@lists.php.net Date: Fri, 22 Apr 2011 18:43:32 -0400 Subject: [PHP-DEV] PHPUnit segfault Hi, I'm a bit lost here. Don't know where to go, since PHP 5.3.6 i'm getting random segfaults using PHPUnit. Xdebug disabledPHPUnit 3.5.13Linux 2.6.18-028stab070.5 #1 SMP Fri Sep 17 15:37:23 MSD 2010 i686 i686 i386 GNU/LinuxCentOS release 5.6 (Final)Apache 2.2.17 I just want to know if i'm on the right place and which tools may i use to debug this.By random segfaults i mean some times a testsuite completes without any trouble,and some other times it fails somwhere in the middle, Regards, Andras
Re: [PHP-DEV] Unmaintained SAPIs
On 4/22/11 6:08 PM, Johannes Schlüter wrote: apache_hooks We can drop apache_hooks as well. I think I was the only one ever to use it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Function proposal: varset
yeah you are right, passing arguments by reference doesn't trigger the notice, but I'm not sure that it is applicable in our case. Yeah, it wouldn't help. For instance, 42 or default can't be passed by reference, so you couldn't actually provide a default value to coalesce() if you implemented it like that, which would make it pretty useless. :-) Ben. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
On 21/04/11 9:56 AM, Arpad Ray wrote:
I must say that the prospect of yet more new syntax is scary. It
really looks like Perl, and I wouldn't have the slightest clue what it
meant if I'd missed the release notes.
I agree it looks a little bit strange. I think that's partly a benefit:
it doesn't look like something so that you assume you know what it means
but get it wrong; it drives you to the manual to find out what it means.
I've pined for something like coalesce($_GET['foo'], $defaults['foo'],
42) for years, and I think that style is far more in keeping with the
PHP ethos, and far more readily understandable than this suggested new
syntax.
As I see it, there a are a number of drawbacks to this approach.
1. It doesn't help with a bunch of common paradigms. For instance,
$a['k'] = isset($a['k']) ? $a['k'] : default
2. I think it's too 'blunt'. For instance, if you write
coalesce($_GET['foo'], $defaults['foo']) you probably actually do want
to see a notice if $defaults['foo'] is not defined. But if you include
42 as a last resort default, you of course do not. Treating the last
argument of a variable number of arguments differently is difficult and
unintuitive, and even that would not always be desired anyway.
Furthermore with something like $o-foo are you interested in whether $o
is defined or not, or only in whether $o-foo is null? Particularly if
you have many arguments, if you don't have tests that give full coverage
of all the possibilities for each argument, notices very helpful for
debugging could be easily undesirably silenced.
3. It can't be equivalent to isset() on every argument. isset() is very
restricted in what it can operate on. For instance, isset(42) is not
legal; nor is isset(some_function()); and so on. This kind of thing
would be important to allow in coalescse(), but it would make things
difficult to parse: to have any chance of making it work, you'd need to
parse each item as if in isset(), and if it fails, backtrack and parse
it as an expression, and then the coalesce() operation(s) (it could not
be a function) would have to be able to deal with both scenarios for
every argument. Nasty.
4. It's misleading regarding side effects because it looks like a
function. If coalesce() were a function and you wrote
coalesce($_GET['foo'],get_default('foo')), you would expect
get_default() to be called before coalesce() and regardless of the state
of $_GET['foo']. If it actually behaved like that, it would render
coalesce() somewhat less useful, but it would be misleading if it didn't
work like that. isset() gets away with this because it is restricted and
only has one argument, but coalesce() wouldn't.
To avoid/solve these problems:
1. Support missing paradigms: I suppose adding coalesce_set() and other
constructs could conceptually provide for that.
2. Less blunt: You really need some kind of notice-free array index
and/or variable lookup that can pinpoint the notice to be omitted. A
function-like syntax doesn't really work: isset(), though better than
coalesce(), is still too blunt for many use cases. It's also very
verbose. Nobody wants to write
coalesce(ifset($_GET['foo']),ifset($defaults['foo']),42)
IMHO, it is better to have
coalesce($_GET[?'foo'],$defaults[?'foo'],42)
even though it's not 'familiar'.
3. Avoid isset()-like restrictions: You can use a !==null test that can
be applied to any expression; if problem 1 is solved satisfactorily, an
expression will simply be evaluated without generating a notice, and
then compared to null.
4. Sensible side-effect behaviour: To get that, you really need an
operator (or other language construct), and a function-like syntax is
misleading. Although unfamiliar,
$_GET[?'foo'] $: $defaults[?'foo'] $: 42
is less misleading. It also extends nicely to the assignment paradigm as
$_GET[?'foo'] $:= $defaults[?'foo'] $: 42;
Ben.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
What does coalesce() do? If I'm guessing correctly, would proposal #2 that Rune Kaagaard put up solve that for you? https://gist.github.com/909711 Rune's proposal #2, extending func_get_arg(), is impossible to implement/would not work. His proposal #3, which is more like coalesce(), suffers from the drawbacks/problems of coalesce() which I discussed in a recent post (though you can see Rune has some workarounds/hacks to deal with some of the problems). IMHO, his proposal #1 is the only real contender. However, I believe it conflates two problems which others do not want conflated. He briefly dismisses the [?] syntax, because it addresses what he sees as a different problem. However, that different problem is really part of his problem. My contention is that the two parts of his problem are better solved independently (notice-suppression separately to finding an isset/!empty value), and furthermore that one of the two versions of his problem is already partially solved and should be reused, not reinvented (existing ternary operator for a !empty check). Ben. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
what about something like this?
$_GET += array( 'key' = 42, 'other' = 'blablah' );
echo $_GET [ 'key' ];
and it's already available on you current instalation :)
Martin Scotta
On Fri, Apr 22, 2011 at 11:27 PM, Ben Schmidt mail_ben_schm...@yahoo.com.au
wrote:
On 21/04/11 9:56 AM, Arpad Ray wrote:
I must say that the prospect of yet more new syntax is scary. It
really looks like Perl, and I wouldn't have the slightest clue what it
meant if I'd missed the release notes.
I agree it looks a little bit strange. I think that's partly a benefit:
it doesn't look like something so that you assume you know what it means
but get it wrong; it drives you to the manual to find out what it means.
I've pined for something like coalesce($_GET['foo'], $defaults['foo'],
42) for years, and I think that style is far more in keeping with the
PHP ethos, and far more readily understandable than this suggested new
syntax.
As I see it, there a are a number of drawbacks to this approach.
1. It doesn't help with a bunch of common paradigms. For instance,
$a['k'] = isset($a['k']) ? $a['k'] : default
2. I think it's too 'blunt'. For instance, if you write
coalesce($_GET['foo'], $defaults['foo']) you probably actually do want
to see a notice if $defaults['foo'] is not defined. But if you include
42 as a last resort default, you of course do not. Treating the last
argument of a variable number of arguments differently is difficult and
unintuitive, and even that would not always be desired anyway.
Furthermore with something like $o-foo are you interested in whether $o
is defined or not, or only in whether $o-foo is null? Particularly if
you have many arguments, if you don't have tests that give full coverage
of all the possibilities for each argument, notices very helpful for
debugging could be easily undesirably silenced.
3. It can't be equivalent to isset() on every argument. isset() is very
restricted in what it can operate on. For instance, isset(42) is not
legal; nor is isset(some_function()); and so on. This kind of thing
would be important to allow in coalescse(), but it would make things
difficult to parse: to have any chance of making it work, you'd need to
parse each item as if in isset(), and if it fails, backtrack and parse
it as an expression, and then the coalesce() operation(s) (it could not
be a function) would have to be able to deal with both scenarios for
every argument. Nasty.
4. It's misleading regarding side effects because it looks like a
function. If coalesce() were a function and you wrote
coalesce($_GET['foo'],get_default('foo')), you would expect
get_default() to be called before coalesce() and regardless of the state
of $_GET['foo']. If it actually behaved like that, it would render
coalesce() somewhat less useful, but it would be misleading if it didn't
work like that. isset() gets away with this because it is restricted and
only has one argument, but coalesce() wouldn't.
To avoid/solve these problems:
1. Support missing paradigms: I suppose adding coalesce_set() and other
constructs could conceptually provide for that.
2. Less blunt: You really need some kind of notice-free array index
and/or variable lookup that can pinpoint the notice to be omitted. A
function-like syntax doesn't really work: isset(), though better than
coalesce(), is still too blunt for many use cases. It's also very
verbose. Nobody wants to write
coalesce(ifset($_GET['foo']),ifset($defaults['foo']),42)
IMHO, it is better to have
coalesce($_GET[?'foo'],$defaults[?'foo'],42)
even though it's not 'familiar'.
3. Avoid isset()-like restrictions: You can use a !==null test that can
be applied to any expression; if problem 1 is solved satisfactorily, an
expression will simply be evaluated without generating a notice, and
then compared to null.
4. Sensible side-effect behaviour: To get that, you really need an
operator (or other language construct), and a function-like syntax is
misleading. Although unfamiliar,
$_GET[?'foo'] $: $defaults[?'foo'] $: 42
is less misleading. It also extends nicely to the assignment paradigm as
$_GET[?'foo'] $:= $defaults[?'foo'] $: 42;
Ben.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
It's good for some situations, but there are plenty more where it doesn't cut it,
e.g. $_GET[?'foo'] $:= get_default_from_db('foo') $: hard-coded.
Ben.
On 23/04/11 12:54 PM, Martin Scotta wrote:
what about something like this?
$_GET += array( 'key' = 42, 'other' = 'blablah' );
echo $_GET [ 'key' ];
and it's already available on you current instalation :)
Martin Scotta
On Fri, Apr 22, 2011 at 11:27 PM, Ben Schmidtmail_ben_schm...@yahoo.com.au
wrote:
On 21/04/11 9:56 AM, Arpad Ray wrote:
I must say that the prospect of yet more new syntax is scary. It
really looks like Perl, and I wouldn't have the slightest clue what it
meant if I'd missed the release notes.
I agree it looks a little bit strange. I think that's partly a benefit:
it doesn't look like something so that you assume you know what it means
but get it wrong; it drives you to the manual to find out what it means.
I've pined for something like coalesce($_GET['foo'], $defaults['foo'],
42) for years, and I think that style is far more in keeping with the
PHP ethos, and far more readily understandable than this suggested new
syntax.
As I see it, there a are a number of drawbacks to this approach.
1. It doesn't help with a bunch of common paradigms. For instance,
$a['k'] = isset($a['k']) ? $a['k'] : default
2. I think it's too 'blunt'. For instance, if you write
coalesce($_GET['foo'], $defaults['foo']) you probably actually do want
to see a notice if $defaults['foo'] is not defined. But if you include
42 as a last resort default, you of course do not. Treating the last
argument of a variable number of arguments differently is difficult and
unintuitive, and even that would not always be desired anyway.
Furthermore with something like $o-foo are you interested in whether $o
is defined or not, or only in whether $o-foo is null? Particularly if
you have many arguments, if you don't have tests that give full coverage
of all the possibilities for each argument, notices very helpful for
debugging could be easily undesirably silenced.
3. It can't be equivalent to isset() on every argument. isset() is very
restricted in what it can operate on. For instance, isset(42) is not
legal; nor is isset(some_function()); and so on. This kind of thing
would be important to allow in coalescse(), but it would make things
difficult to parse: to have any chance of making it work, you'd need to
parse each item as if in isset(), and if it fails, backtrack and parse
it as an expression, and then the coalesce() operation(s) (it could not
be a function) would have to be able to deal with both scenarios for
every argument. Nasty.
4. It's misleading regarding side effects because it looks like a
function. If coalesce() were a function and you wrote
coalesce($_GET['foo'],get_default('foo')), you would expect
get_default() to be called before coalesce() and regardless of the state
of $_GET['foo']. If it actually behaved like that, it would render
coalesce() somewhat less useful, but it would be misleading if it didn't
work like that. isset() gets away with this because it is restricted and
only has one argument, but coalesce() wouldn't.
To avoid/solve these problems:
1. Support missing paradigms: I suppose adding coalesce_set() and other
constructs could conceptually provide for that.
2. Less blunt: You really need some kind of notice-free array index
and/or variable lookup that can pinpoint the notice to be omitted. A
function-like syntax doesn't really work: isset(), though better than
coalesce(), is still too blunt for many use cases. It's also very
verbose. Nobody wants to write
coalesce(ifset($_GET['foo']),ifset($defaults['foo']),42)
IMHO, it is better to have
coalesce($_GET[?'foo'],$defaults[?'foo'],42)
even though it's not 'familiar'.
3. Avoid isset()-like restrictions: You can use a !==null test that can
be applied to any expression; if problem 1 is solved satisfactorily, an
expression will simply be evaluated without generating a notice, and
then compared to null.
4. Sensible side-effect behaviour: To get that, you really need an
operator (or other language construct), and a function-like syntax is
misleading. Although unfamiliar,
$_GET[?'foo'] $: $defaults[?'foo'] $: 42
is less misleading. It also extends nicely to the assignment paradigm as
$_GET[?'foo'] $:= $defaults[?'foo'] $: 42;
Ben.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
