Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/14/2014 12:51 AM, Levi Morrison wrote: While I think long-term this would be a beneficial change I think in the short term it's quite a hurdle. This discussion will be identical whether we wait till PHP7 or PHP9 in a decade. The longer this change takes to make, the more code that will be mis-written to rely on the current behavior. If any long-term benefit is to be reaped, now is the best time to do it - every future major version will have a harder justification to make. There is definitely code out there relying on this behavior and changing it will result in the worst BC case: it will not fail in any way but will instead act differently. There are also definitely IE5.5 users out there and websites that rely on IE5.5-only features, but the actual numbers matter. There's no doubt that somebody, somewhere is going to have broken code because they wrote it without reading the docs that recommend against it or without understanding how it works, or upgraded without reading a migration guide or realizing that major version upgrades do make breaking changes (more often than not). These people do exist and they may curse PHP rather than themselves and leave it forever; the desire of the core team to retain the maximum amount of these users is puzzling. The change under discussion will not be causing any sort of mass-exodus from PHP, the ecosystem will not collapse and it will not be the heat-death of the universe. It will be removing a long-discouraged behavior and bring expected uniformity to a common construct that has differed for no good reason from other languages. There's plenty of room for a #5 on the already non-0 list: https://wiki.php.net/phpng#incompatibilities_made_on_purpose_and_are_not_going_to_be_fixed In my opinion, chaining or nesting ternaries at all should be discouraged; changing the associativity doesn't change the fact that they are more difficult to follow and more error prone than using different constructs. I would disagree on this point. Just like there are cases where a large switch/case results in more readable if-elseif chains, long conditional assignment chains can serve the same purpose, granted you space them appropriately. I would even go as far as saying that with proper spacing, they are more readable than the 'if' or 'case' blocks that would need to replace them. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 14 December 2014 at 08:24, Leon Sorokin leeon...@gmail.com wrote: On 12/14/2014 12:51 AM, Levi Morrison wrote: While I think long-term this would be a beneficial change I think in the short term it's quite a hurdle. This discussion will be identical whether we wait till PHP7 or PHP9 in a decade. The longer this change takes to make, the more code that will be mis-written to rely on the current behavior. If any long-term benefit is to be reaped, now is the best time to do it - every future major version will have a harder justification to make. There is definitely code out there relying on this behavior and changing it will result in the worst BC case: it will not fail in any way but will instead act differently. There are also definitely IE5.5 users out there and websites that rely on IE5.5-only features, but the actual numbers matter. There's no doubt that somebody, somewhere is going to have broken code because they wrote it without reading the docs that recommend against it or without understanding how it works, or upgraded without reading a migration guide or realizing that major version upgrades do make breaking changes (more often than not). These people do exist and they may curse PHP rather than themselves and leave it forever; the desire of the core team to retain the maximum amount of these users is puzzling. The change under discussion will not be causing any sort of mass-exodus from PHP, the ecosystem will not collapse and it will not be the heat-death of the universe. It will be removing a long-discouraged behavior and bring expected uniformity to a common construct that has differed for no good reason from other languages. There's plenty of room for a #5 on the already non-0 list: https://wiki.php.net/phpng#incompatibilities_made_on_ purpose_and_are_not_going_to_be_fixed In my opinion, chaining or nesting ternaries at all should be discouraged; changing the associativity doesn't change the fact that they are more difficult to follow and more error prone than using different constructs. I would disagree on this point. Just like there are cases where a large switch/case results in more readable if-elseif chains, long conditional assignment chains can serve the same purpose, granted you space them appropriately. I would even go as far as saying that with proper spacing, they are more readable than the 'if' or 'case' blocks that would need to replace them. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php If you wanted an upgrade path that was not Evil (in the sense of not introducing subtle and hard-to-diagnose bugs), could you not change the operator to be *un*associative in PHP7? That would effectively just make concrete the discouragement/deprecation that's already in the documentation, and would produce irritating but very visible errors for anyone still actually using this functionality, as well as making them alter their code in a forward-compatible way. Then if you want to think really long term, plan to implement the 'correct' associativity in the *next* major version. --G
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 14 Dec 2014, at 12:01, George Bond happy.melon.wiki...@gmail.com wrote: If you wanted an upgrade path that was not Evil (in the sense of not introducing subtle and hard-to-diagnose bugs), could you not change the operator to be *un*associative in PHP7? That would effectively just make concrete the discouragement/deprecation that's already in the documentation, and would produce irritating but very visible errors for anyone still actually using this functionality, as well as making them alter their code in a forward-compatible way. Then if you want to think really long term, plan to implement the 'correct' associativity in the *next* major version. Hey George, That sounds like a good approach, actually, although I'm not sure about later fixing the associativity. If we make it non-associative this does break things, but very loudly rather than changing code's behaviour. I think we should do this. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Sunday, December 14, 2014 2:26 PM To: George Bond Cc: PHP internals Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0? On 14 Dec 2014, at 12:01, George Bond happy.melon.wiki...@gmail.com wrote: If you wanted an upgrade path that was not Evil (in the sense of not introducing subtle and hard-to-diagnose bugs), could you not change the operator to be *un*associative in PHP7? That would effectively just make concrete the discouragement/deprecation that's already in the documentation, and would produce irritating but very visible errors for anyone still actually using this functionality, as well as making them alter their code in a forward-compatible way. Then if you want to think really long term, plan to implement the 'correct' associativity in the *next* major version. Hey George, That sounds like a good approach, actually, although I'm not sure about later fixing the associativity. If we make it non-associative this does break things, but very loudly rather than changing code's behaviour. I think we should do this. Although my inclination would be not to change anything, I agree that if we do decide to change it, George's idea is the best approach. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Native TLS
On Wed, Dec 10, 2014 at 8:46 PM, Dmitry Stogov dmi...@zend.com wrote: +1 the patch is great. It doesn't affect non-ZTS build at all. ZTS build became even a bit faster. :) And we finally will able to forget about TSRMLS_ macros :) Say what? this is music to my ears :) Thanks for the patch. Non-ZTS ZTS master native-tls master native-tls bench.php [sec] 1.193 1.195 1.313 1.299 micro_bench.php [sec] 6.008 6.064 7.470 6.786 Wordpress-3.6 -T 1000 [sec] 13.308 13.293 14.997 14.611 bench.php [Mops] 7,055 7,055 7,885 7,342 Wordpress-3.6 -T 100 [Mops] 3,093 3,093 3,743 3,483 Mops - millions of instruction fetches measured using callgrind (the less the better) The solution requires minor changes in every third party extension, but it's really small cost for significant step forward. Thanks. Dmitry. On Wed, Dec 10, 2014 at 10:04 PM, Anatol Belski anatol@belski.net wrote: Hi, hereby the voting on https://wiki.php.net/rfc/native-tls#vote is opened. The vote starts on 12/10/2014 at 21:00 CET and ends on 12/17/2014 at 21:00 CET. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
This sounds like a reasonable compromise to me and infinitely better than doing nothing. However, if 7.0 complains loudly enough about this already quasi-deprecated pattern, then the incubation period for an eventual fix need not be that of a decade-out major version, but of a 7.x point release. Oddly, 5.4 is a good example of a much larger incompatibility changelog than the provisional one for 7.0: http://php.net/manual/en/migration54.incompatible.php -- Leon Sorokin On 12/14/2014 6:01 AM, George Bond wrote: On 14 December 2014 at 08:24, Leon Sorokin leeon...@gmail.com wrote: On 12/14/2014 12:51 AM, Levi Morrison wrote: While I think long-term this would be a beneficial change I think in the short term it's quite a hurdle. This discussion will be identical whether we wait till PHP7 or PHP9 in a decade. The longer this change takes to make, the more code that will be mis-written to rely on the current behavior. If any long-term benefit is to be reaped, now is the best time to do it - every future major version will have a harder justification to make. There is definitely code out there relying on this behavior and changing it will result in the worst BC case: it will not fail in any way but will instead act differently. There are also definitely IE5.5 users out there and websites that rely on IE5.5-only features, but the actual numbers matter. There's no doubt that somebody, somewhere is going to have broken code because they wrote it without reading the docs that recommend against it or without understanding how it works, or upgraded without reading a migration guide or realizing that major version upgrades do make breaking changes (more often than not). These people do exist and they may curse PHP rather than themselves and leave it forever; the desire of the core team to retain the maximum amount of these users is puzzling. The change under discussion will not be causing any sort of mass-exodus from PHP, the ecosystem will not collapse and it will not be the heat-death of the universe. It will be removing a long-discouraged behavior and bring expected uniformity to a common construct that has differed for no good reason from other languages. There's plenty of room for a #5 on the already non-0 list: https://wiki.php.net/phpng#incompatibilities_made_on_ purpose_and_are_not_going_to_be_fixed In my opinion, chaining or nesting ternaries at all should be discouraged; changing the associativity doesn't change the fact that they are more difficult to follow and more error prone than using different constructs. I would disagree on this point. Just like there are cases where a large switch/case results in more readable if-elseif chains, long conditional assignment chains can serve the same purpose, granted you space them appropriately. I would even go as far as saying that with proper spacing, they are more readable than the 'if' or 'case' blocks that would need to replace them. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php If you wanted an upgrade path that was not Evil (in the sense of not introducing subtle and hard-to-diagnose bugs), could you not change the operator to be *un*associative in PHP7? That would effectively just make concrete the discouragement/deprecation that's already in the documentation, and would produce irritating but very visible errors for anyone still actually using this functionality, as well as making them alter their code in a forward-compatible way. Then if you want to think really long term, plan to implement the 'correct' associativity in the *next* major version. --G -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Consistent type names in error messages
Good evening,
Unfortunately, zend_parse_parameters and userland type hint error messages use
outdated type names, and don’t even do so consistently. For example:
$ php -r 'fread(0, 0);'
PHP Warning: fread() expects parameter 1 to be resource, integer given in
Command line code on line 1
$ php -r 'fread(fopen(data:text/plain,test, r),
fopen(data:text/plain,test, r));'
PHP Warning: fread() expects parameter 2 to be long, resource given in Command
line code on line 1
$ php -r 'function foo(foobar $x) {} foo(1.0);'
PHP Catchable fatal error: Argument 1 passed to foo() must be an instance of
foobar, double given, called in Command line code on line 1 and defined in
Command line code on line 1
Specifically, zend_parse_parameters will always “expect” a “long”, yet when the
expected type isn’t an integer and an integer is passed, it says “integer
given”. Alongside this, both userland type hint errors and
zend_parse_parameters errors refer to “double” and not “float”.
I want to change the type names to be consistent, because I think our current
inconsistency is confusing. Integers are sometimes ints or integers, but other
times longs. Floats are sometimes floats, but other times doubles. If scalar
type hints are ever added, then jettisoning the old aliases means we don’t have
to add extra reserved words.
I’ve made a patch which makes zend_parse_parameters and userland type hints
consistently show “integer” and “float” rather than “long” and “double”:
https://github.com/php/php-src/pull/955
I also wrote a GNU sed script which I used to update the tests:
https://gist.github.com/TazeTSchnitzel/c0d780466def9f226318
Alongside error messages, there are some other places that could be changed.
Obviously the return value of gettype() shouldn’t be changed, but I think that
we should, for example, make is_long() an alias of is_int() and not the other
way around.
Thoughts?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Consistent type names in error messages
2014-12-14 19:35 GMT+01:00 Andrea Faulds a...@ajf.me:
Good evening,
Unfortunately, zend_parse_parameters and userland type hint error messages
use outdated type names, and don’t even do so consistently. For example:
$ php -r 'fread(0, 0);'
PHP Warning: fread() expects parameter 1 to be resource, integer given in
Command line code on line 1
$ php -r 'fread(fopen(data:text/plain,test, r),
fopen(data:text/plain,test, r));'
PHP Warning: fread() expects parameter 2 to be long, resource given in
Command line code on line 1
$ php -r 'function foo(foobar $x) {} foo(1.0);'
PHP Catchable fatal error: Argument 1 passed to foo() must be an instance of
foobar, double given, called in Command line code on line 1 and defined in
Command line code on line 1
Specifically, zend_parse_parameters will always “expect” a “long”, yet when
the expected type isn’t an integer and an integer is passed, it says “integer
given”. Alongside this, both userland type hint errors and
zend_parse_parameters errors refer to “double” and not “float”.
I want to change the type names to be consistent, because I think our current
inconsistency is confusing. Integers are sometimes ints or integers, but
other times longs. Floats are sometimes floats, but other times doubles. If
scalar type hints are ever added, then jettisoning the old aliases means we
don’t have to add extra reserved words.
You forgot that they can also be 'real', but on a serious manner, I
don't see any reason not to make the error messages consistent and I
would say go ahead already.
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Consistent type names in error messages
Hi Kalle, On 14 Dec 2014, at 18:41, Kalle Sommer Nielsen ka...@php.net wrote: 2014-12-14 19:35 GMT+01:00 Andrea Faulds a...@ajf.me: I want to change the type names to be consistent, because I think our current inconsistency is confusing. Integers are sometimes ints or integers, but other times longs. Floats are sometimes floats, but other times doubles. If scalar type hints are ever added, then jettisoning the old aliases means we don’t have to add extra reserved words. You forgot that they can also be 'real', but on a serious manner, I don't see any reason not to make the error messages consistent and I would say go ahead already. Aha, yes, I did forget that real is also an alias of float. I suppose this proves my point that all these aliases are confusing: I can’t even remember them all! Also, a sidenote: In case someone goes and checks the manual and tells me that is_long() is already an alias of is_int() and not the other way around, the manual lies. In fact, is_int() is currently an alias of is_long() in master. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 7 and json
Hi, On Wed, Dec 10, 2014 at 6:43 AM, Remi Collet r...@fedoraproject.org wrote: The main issue is the non-free decoder. Agreed. Of course perf can be considered as an issue (I think minor). jsonc have bad perf, but is free. If jsond have nearly same perf than old one, it's enough. My initial benchmarks (for PHP5 jsond ext) actually shows better performance for json instances containing strings. Pure int and floats are more or less the same. But need more benchmarks to confirm that. Just a quick update on jsond. The decoder is mostly done. So, please go on I have ported a decoder to PHP 7. The code can be found on my github php-src jsond branch ( for code changes see https://github.com/bukka/php-src/compare/jsond ). It's just a replaced decoder. The encoder is the same though. All tests are passing for me... I haven't done any perf tests as yet. There is a big room for improvements but it's a good start IMHO. I'll have more time during Christmas so I would like to improve the code and do some benchmarks. Think we could have RFC around New Year... I have been recently working on optimization for the encoder. I already have over 30% speed improvement in encoding for string based arrays/objects like $_SERVER. It's generally much faster now but there is still a big room for other impromevents. I also experiment with a new buffer (replacement for smart_str in json encoder). It needs lots of optimization but it already gives better numbers for some cases. However it also gives worse numbers for some other cases like processing small integers so I need to play with it a bit more. As I said before I need a better set of benchmarks to be sure that it works fine for a big number of json instances. Current encoder is not an issue. Perf. can be manage later. And I don't think we should use another string management for json encoder, so if improvment is possible, should go in smart_str. Yeah I won't go there (replacing smart_str). It's still experimental and it would delay the whole thing quite a lot. I'll rather add just few proven improvements that are already done in jsond and that are not breaking ABI. Cheers Jakub
Re: [PHP-DEV] PHP 7 and json
I don’t know if you are interested in some other open source projects that parse JSON, but have you looked at the decoder here? https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl It can parse more than just the JSON format - but it has some JSON benchmarks attached and works really well - and is plain C. Am 14.12.2014 um 20:38 schrieb Jakub Zelenka bu...@php.net: Hi, On Wed, Dec 10, 2014 at 6:43 AM, Remi Collet r...@fedoraproject.org wrote: The main issue is the non-free decoder. Agreed. Of course perf can be considered as an issue (I think minor). jsonc have bad perf, but is free. If jsond have nearly same perf than old one, it's enough. My initial benchmarks (for PHP5 jsond ext) actually shows better performance for json instances containing strings. Pure int and floats are more or less the same. But need more benchmarks to confirm that. Just a quick update on jsond. The decoder is mostly done. So, please go on I have ported a decoder to PHP 7. The code can be found on my github php-src jsond branch ( for code changes see https://github.com/bukka/php-src/compare/jsond ). It's just a replaced decoder. The encoder is the same though. All tests are passing for me... I haven't done any perf tests as yet. There is a big room for improvements but it's a good start IMHO. I'll have more time during Christmas so I would like to improve the code and do some benchmarks. Think we could have RFC around New Year... I have been recently working on optimization for the encoder. I already have over 30% speed improvement in encoding for string based arrays/objects like $_SERVER. It's generally much faster now but there is still a big room for other impromevents. I also experiment with a new buffer (replacement for smart_str in json encoder). It needs lots of optimization but it already gives better numbers for some cases. However it also gives worse numbers for some other cases like processing small integers so I need to play with it a bit more. As I said before I need a better set of benchmarks to be sure that it works fine for a big number of json instances. Current encoder is not an issue. Perf. can be manage later. And I don't think we should use another string management for json encoder, so if improvment is possible, should go in smart_str. Yeah I won't go there (replacing smart_str). It's still experimental and it would delay the whole thing quite a lot. I'll rather add just few proven improvements that are already done in jsond and that are not breaking ABI. Cheers Jakub
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 14 December 2014 17:31:52 GMT, Leon Sorokin leeon...@gmail.com wrote: This sounds like a reasonable compromise to me and infinitely better than doing nothing. However, if 7.0 complains loudly enough about this already quasi-deprecated pattern, then the incubation period for an eventual fix need not be that of a decade-out major version, but of a 7.x point release. Oddly, 5.4 is a good example of a much larger incompatibility changelog than the provisional one for 7.0: http://php.net/manual/en/migration54.incompatible.php 5.4 is a good example of what we *don't* want to do with minor versions. It consisted of a messy list of those bits of the abandoned 6 which didn't quite make it into 5.3. If we want major features more often, we can have major releases more often. This figure of 10 years gets mentioned a lot, but with annual releases, it wouldn't be unreasonable to expect 8.0 by 2020 (a year after 7.4). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 7 and json
Hi Kevin, On 14 Dec 2014, at 19:46, Kevin Ingwersen (Ingwie Phoenix) ingwie2...@googlemail.com wrote: I don’t know if you are interested in some other open source projects that parse JSON, but have you looked at the decoder here? https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl It can parse more than just the JSON format - but it has some JSON benchmarks attached and works really well - and is plain C. That isn’t a JSON parser, it parses its own format which seems to be a superset of JSON. Also, we really need something custom-tailored to PHP’s needs (i.e. produces PHP types). Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Consistent type names in error messages
2014-12-14 19:44 GMT+01:00 Andrea Faulds a...@ajf.me: Hi Kalle, Hi Andrea Also, a sidenote: In case someone goes and checks the manual and tells me that is_long() is already an alias of is_int() and not the other way around, the manual lies. In fact, is_int() is currently an alias of is_long() in master. Simple fix: http://pastie.org/9780416 Alternatively I can update the manual to be accurate, but I believe that is_long() should be an alias of is_int() too, so I'll rather change the C source which it has no impact on userland anyway. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Consistent type names in error messages
On 14 Dec 2014, at 19:59, Kalle Sommer Nielsen ka...@php.net wrote: 2014-12-14 19:44 GMT+01:00 Andrea Faulds a...@ajf.me: Hi Kalle, Hi Andrea Also, a sidenote: In case someone goes and checks the manual and tells me that is_long() is already an alias of is_int() and not the other way around, the manual lies. In fact, is_int() is currently an alias of is_long() in master. Simple fix: http://pastie.org/9780416 Alternatively I can update the manual to be accurate, but I believe that is_long() should be an alias of is_int() too, so I'll rather change the C source which it has no impact on userland anyway. It wouldn’t break anything, I say make a pull request. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 14/12/14 19:48, Rowan Collins wrote: 5.4 is a good example of what we *don't* want to do with minor versions. It consisted of a messy list of those bits of the abandoned 6 which didn't quite make it into 5.3. 5.4 should have been '6' with a 5.4 that provided the very same buffer that 5.7 is now envisaged to provide with PHP7. There is still a substantial code base reliant on legacy features such as register_globals which requires substantial work to move from 5.3 to 5.4 and it is stumbling blocks like these which are STILL holding up adoption of later versions with ISP's. Anything 'broken' in PHP7 must have a managed upgrade path helped by warnings in 5.7, and I'd even go as far as to say that proposed patches for things like this fix should include migration tools before being merged! So both 5.7 and 7 are required to prevent a rerun of previous chaos ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Consistent type names in error messages
Hi Andrea 2014-12-14 21:01 GMT+01:00 Andrea Faulds a...@ajf.me: It wouldn’t break anything, I say make a pull request. See: http://news.php.net/php.cvs/83688 http://news.php.net/php.doc.cvs/12965 -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Consistent type names in error messages
On 14/12/2014 18:35, Andrea Faulds wrote:
Good evening,
Unfortunately, zend_parse_parameters and userland type hint error messages use
outdated type names, and don’t even do so consistently. For example:
$ php -r 'fread(0, 0);'
PHP Warning: fread() expects parameter 1 to be resource, integer given in
Command line code on line 1
$ php -r 'fread(fopen(data:text/plain,test, r), fopen(data:text/plain,test,
r));'
PHP Warning: fread() expects parameter 2 to be long, resource given in Command
line code on line 1
$ php -r 'function foo(foobar $x) {} foo(1.0);'
PHP Catchable fatal error: Argument 1 passed to foo() must be an instance of
foobar, double given, called in Command line code on line 1 and defined in
Command line code on line 1
Specifically, zend_parse_parameters will always “expect” a “long”, yet when the
expected type isn’t an integer and an integer is passed, it says “integer
given”. Alongside this, both userland type hint errors and
zend_parse_parameters errors refer to “double” and not “float”.
I want to change the type names to be consistent, because I think our current
inconsistency is confusing. Integers are sometimes ints or integers, but other
times longs. Floats are sometimes floats, but other times doubles. If scalar
type hints are ever added, then jettisoning the old aliases means we don’t have
to add extra reserved words.
I’ve made a patch which makes zend_parse_parameters and userland type hints
consistently show “integer” and “float” rather than “long” and “double”:
https://github.com/php/php-src/pull/955
I also wrote a GNU sed script which I used to update the tests:
https://gist.github.com/TazeTSchnitzel/c0d780466def9f226318
Alongside error messages, there are some other places that could be changed.
Obviously the return value of gettype() shouldn’t be changed, but I think that
we should, for example, make is_long() an alias of is_int() and not the other
way around.
Thoughts?
I had a go at this a few months ago, but haven't updated my patch based
on what's changed in the engine since, so it probably wouldn't merge
cleanly: https://github.com/php/php-src/pull/769
An additional case which it looks like you haven't covered is Object of
class %s could not be converted to double in zend_operators.c and
zend_object_handlers.c:
https://github.com/IMSoP/php-src/commit/8dd601ac39a4241c9f119fd2d3e0e46474980a53
Other than the awkward BC implications in gettype(), I see no reason
that the user should ever see the types labelled as long or double
in their output.
However, note that zend_get_type_by_const does get used in a handful of
non-error contexts, such as the ReflectionClass output shown in
ext/reflection/tests/bug29986.phpt
[https://github.com/TazeTSchnitzel/php-src/commit/c0ee87297298b4ff9b8d68a01f8bbb99f94d9a10#diff-241]
I had a grep around and couldn't see any that were likely to cause any
real concern, though.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
Some thoughts from user land… On the concern of breaking code out there that relies on the current behavior, I strongly suspect far more code would be *fixed* if the ternary operator were changed to match what other languages do. I hate to admit it, but my own shop is a good example. We have a particular application that has thousands of business rules in the form of boolean expressions written using the ternary operator. When I took over the application, every one of them that was non-trivial (i.e., 95% of them) was wrong because the developers who wrote them didn’t understand how the operator works. It’s still a problem. If the operator were fixed in v7 — really fixed, not just made non-associative — all those rules would magically work; that alone would present a strong impetus for us to migrate that app. And the problem isn’t restricted to “those” guys that worked on that application back in the dark ages. The folks working here now still struggle with ternary if they haven’t used it recently. They’ve had enough code flagged in reviews to know that it’s problematic, but the usual solution is to rewrite it with switch or if-else, or to go crazy with parentheses. Either way, their code won’t break if the operator is fixed. I’ve also interviewed a lot of PHP developers, and I usually ask about the ternary operator. Depending on their experience level, my hope is that they either A) know all about it and can use it without fear, but are respectful of the confusion it can cause others, or B) they don’t really understand it, but they know it can bite them so that they’re careful if they encounter it or feel the need to use it. The vast majority of the time, however, I get C) they think they know all about it and have no fear of using it — but their understanding is completely wrong. This is across the board, all experience levels from junior guys with a year under their belts to senior guys with 10+ years. So, it seems that very few PHP developers actually understand how the ternary operator works in PHP. And those that do, because they tend to rarely use it in nested form, usually either just avoid doing so even when it makes sense or uses parentheses to avoid having to think too hard. Either way, their code is probably safe, and even if it’s not, nested use of ternary is so rare in most code bases that a manual review is not too troublesome. As for the vast majority of developers who don’t understand the operator: the code everyone here is so worried about breaking is largely written by these folks, and *it’s already broken*. Fixing the ternary operator now will only help most of this code, while making it non-associative will break the code in a different way while also breaking the code of those who do understand the operator. Fixing it now, or changing it now to fix it later - either way, working code that doesn’t rely on parentheses needs to be adjusted. Fortunately, the nested ternary is a rare beast (in most apps, anyway), but even so, most folks would like to do that review only once. And if it’s to adjust code to work more sanely, the way most other languages do it, well, it stings a lot less in that case. So my opinion, as a manager of millions of lines of closed-source code that I know no one else will fix for me, is to make changes to the ternary operator just once, and make that change one that fixes it to fit most people’s expectations. That’s the path that would be most beneficial to me. -- Bob Williams SVP, Software Development Newtek Business Services, Inc. “The Small Business Authority” http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).
[PHP-DEV] old RFC vote
Hi! The RFC https://wiki.php.net/rfc/aliases_by_reflection is still in voting status (with 1:7 result so far) - I assume by now we can close the vote and put it into the rejected list? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/14/2014 10:45 PM, Robert Williams wrote: I strongly suspect far more code would be *fixed* if the ternary operator were changed to match what other languages do. I appreciate your support, but either I am not understanding you, or your reasoning is unsound. If you have 'incorrectly' functioning code today that results in passing unit tests and a correctly functioning business. Then a sudden change to the behavior of this code would necessarily result in failing unit tests and an incorrectly functioning business. The code may be 'fixed' from a semantic point of view, but the logic would be broken from a required-output point of view relative to how it was operating previously, regardless of whether it was understood or not when it was written. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
