Re: [PHP-DEV] [RFC] Syntax for variadic functions
Am 28.08.2013 21:27, schrieb Matthew Leverton:
On Wed, Aug 28, 2013 at 10:47 AM, Nikita Popov nikita@gmail.com wrote:
snip
Would any functions get deprecated as a result of this? e.g., func_get_args()
snip
It's not a good idea to deprecate the function
func_get_args/func_num_args() because it is used in user land code to
detect if a function was called with a specific argument like the following:
function ($argByRef = null) {
if (func_num_args() 1) {
// do expensive stuff to set $argByRef
$argByRef = true;
}
return false;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] More powerful (and backward compatible) API of random number generator functions
Idea for an RFC for a more powerful (and backward compatible) API of random number generator functions. The following psaudocode is self explained (hopfully) const RAND_ALGO_LIBC const RAND_ALGO_MERSENNE_TWISTER const RAND_ALGO_OPENSSL const RAND_ALGO_GMP ... // changed functions (added optional $algo argument) void srand($seed = null, $algo = rand_algo_default()) int rand($min = 0, $max = getrandmax(), $algo = rand_algo_default()) mixed array_rand(array $input, $num_req = 1, $algo = rand_algo_default()) bool shuffle(array $array, $algo = rand_algo_default()) string str_shuffle(string $str, $algo = rand_algo_default()) // new functions // set/get the default algo int rand_algo_default($algo = null) // get a list of available algos array rand_algo_list() // generate random $length bytes string str_rand($length = 1, $algo = rand_algo_default()) // deprecate functions mt_srand() mt_rand() mt_getrandmax() openssl_random_pseudo_bytes() gmp_random() What do you think? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions
Am 29.08.2013 14:00, schrieb Ángel González: Marc Bennewitz wrote: Idea for an RFC for a more powerful (and backward compatible) API of random number generator functions. The following psaudocode is self explained (hopfully) const RAND_ALGO_LIBC const RAND_ALGO_MERSENNE_TWISTER const RAND_ALGO_OPENSSL const RAND_ALGO_GMP (...) What do you think? Why do you want them? The constants exists to have a more readable (and standardizes) name of algorithms and helps the developer which algorithms exists without calling rand_algo_list(). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions
Am 30.08.2013 04:30, schrieb Yasuo Ohgaki: On Thu, Aug 29, 2013 at 9:00 PM, Ángel González keis...@gmail.com wrote: Marc Bennewitz wrote: Idea for an RFC for a more powerful (and backward compatible) API of random number generator functions. The following psaudocode is self explained (hopfully) const RAND_ALGO_LIBC const RAND_ALGO_MERSENNE_TWISTER const RAND_ALGO_OPENSSL const RAND_ALGO_GMP (...) What do you think? Why do you want them? This proposal is good because we need the best random function available in a system with easy to use API. I would like to see the best algorithm in a system as default. Defining the best algorithm as the standard default would be great but what is the best algorithm? Some are fast but less secure and other are more secure but slow. Some times ago i read a feature request to implement the mersenne twister algorithm for rand/shuffle/array_rand but this was closed because it would be a bc break. (can't find it new). Best Regards Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions
Am 31.08.2013 03:17, schrieb Bryan C. Geraghty: First, I want to ask: Does anyone else think we should draw a distinction between RNGs and CSPRNGs? I ask this because the OpenSSL option here is the only CSPRNG; The others are trivially breakable and should not be used for cryptographic applications. I could see an argument for wanting to use them in non-security contexts but I'm wondering if the API should make it clear when that is being done. Secondly, a good place to look for defining a standard secure CSPRNG is FIPS 1402 Annex C (csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf) The listed constants are the one currently available in PHP. No more no less. I agree to have a CSPRNG defined as default but this should be the case on all systems also without openssl dev/urandom ... (I don't know if FIPS 1402 Annex C works on all systems). For other modules like openssl/gmp it should be possible to add there own algorithm that can be used with the same simple API. Bryan -Original Message- From: Marc Bennewitz [mailto:p...@marc-bennewitz.de] Sent: Friday, August 30, 2013 2:59 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions Am 30.08.2013 04:30, schrieb Yasuo Ohgaki: On Thu, Aug 29, 2013 at 9:00 PM, Ángel González keis...@gmail.com wrote: Marc Bennewitz wrote: Idea for an RFC for a more powerful (and backward compatible) API of random number generator functions. The following psaudocode is self explained (hopfully) const RAND_ALGO_LIBC const RAND_ALGO_MERSENNE_TWISTER const RAND_ALGO_OPENSSL const RAND_ALGO_GMP (...) What do you think? Why do you want them? This proposal is good because we need the best random function available in a system with easy to use API. I would like to see the best algorithm in a system as default. Defining the best algorithm as the standard default would be great but what is the best algorithm? Some are fast but less secure and other are more secure but slow. Some times ago i read a feature request to implement the mersenne twister algorithm for rand/shuffle/array_rand but this was closed because it would be a bc break. (can't find it new). Best Regards Marc -- 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
Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions
Am 01.09.2013 15:12, schrieb Jakub Zelenka: The whole proposal is a bit confusing for me. The combination of PRNG algorithm (MT) with libraries (libc, OpenSSL, GMP) that implements one or more PRNG algorithms just doesn't make sense to me. It doesn't say anything about the speed and crypto strength of the algorithms. I think that much better solution would be an extension that implements a couple of algorithms. Then you could select what algorithm you want to use. The good idea would be to have some reasonable default algorithm that would be used if the user doesn't know anything about algorithms. This could be implemented as an extension and if it's good enough then it could be proposed as the core addition. Agree, libc, openssl etc. are not algorithms and the name should reflect the used algorithm not the name of the library. Implementing it as an extension is ok - but the proposal also was to have more possibilities without bc using the default build-in functions. Additionally it would be great to have one standard API other extension can attach it's own algorithm to. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Locale-independent double-to-string cast
Am 02.10.2013 20:38, schrieb Adam Harvey: On 2 October 2013 10:57, Christopher Jones christopher.jo...@oracle.com wrote: On 10/02/2013 10:26 AM, Nikita Popov wrote: I'd like to change our double-to-string casting behavior to be locale-independent and would appreciate some opinions as to whether you consider this feasible. I'd like to see float/double casts recognize the locale's decimal separator. That's an interesting idea, and arguably one that's more in line with what PHP has been doing. I'd be really interested to hear from people in countries where the decimal separator is a comma, since I don't have any experience with this myself as an Anglophone — do you run PHP in your native locale, and if so, would it be better to always have dots, as Nikita suggests, or support parsing numbers with commas? (Or some combination therein.) +1 This is an issue I often ran into. In my opinion on type casting a value from/to string it should use the standard computer format and not a localized one. To format to a localized format we have a function named number_format and since PHP 5.3 the class NumberFormatter. Additionally setlocale is a process operation that makes issues on multi threaded envs. So temporary reset the locale isn't same, too. My little two cent from germany Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of php_mt_rand() rather than php_rand()
Hi Yasuo,
Some times ago I mailed my idea about refactoring random number
generator API with min BC breaks but I didn't create an RFC right now.
see http://marc.info/?l=php-internalsm=137772363015217
Marc
On 16.07.2014 07:13, Yasuo Ohgaki wrote:
Hi all,
There are few places that uses php_rand() currently.
https://bugs.php.net/bug.php?id=66718
http://lxr.php.net/search?q=php_randdefs=refs=path=hist=project=PHP_5_5
These functions could use php_mt_rand() instead of php_rand().
php_rand() uses several rand functions
62PHPAPI long php_rand(TSRMLS_D)
63{
64long ret;
65
66if (!BG(rand_is_seeded)) {
67php_srand(GENERATE_SEED() TSRMLS_CC);
68}
69
70#ifdef ZTS
71ret = php_rand_r(BG(rand_seed));
72#else
73# if defined(HAVE_RANDOM)
74ret = random();
75# elif defined(HAVE_LRAND48)
76ret = lrand48();
77# else
78ret = rand();
79# endif
80#endif
81
82return ret;
83}
Most systems use random() which has cycle of 16 * ((2^31) - 1),
while MT rand has 2^19937-1.
php_mt_rand() could be used where php_rand() is used. Unlike php_rand(),
php_mt_rand() does not check if it is seeded or not. It should be changed
to check seed status.
The only BC issue I can think of is game that expects the same pseudo
random sequences. These apps may use mt_srand() to get fixed random
sequences and adjust their apps if it is needed. This is acceptable BC
for new releases. IMO.
It would be good idea to support 64bit version of MT on 64bit platforms,
too.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt64.html
Any comments?
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] unsinged integer
Hi all, I like to create an RFC to add an unsinged integer type for the following purposes: - higher max value - DBs already allow UNSIGNED INT/BIGINT which is a farce to work with in PHP - better support pack/unpack unsigned integers from/to PHP using the un/pack functions - simplified right shift of unsinged integers because PHP safes the sing bit on singed integers which leads to bugs or overcomplicated code if you need that bit for others than a sign - if a parameter type-hint or similar functionality will be implemented this type will be very useful, too. Else it will be also useful to make sure you have no negative integer by simply converting to it. What do you think? (Does it worth the expense for a RFC?) Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ML issue: new tld's like .berlin doesn't work
Hi all, I have a new email address ending @mabe.berlin but I can't confirm this in the ML :( Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] unsinged integer
Hi all, I like to create an RFC to add an unsinged integer type for the following purposes: - higher max value - DBs already allow UNSIGNED INT/BIGINT which is a farce to work with in PHP - better support pack/unpack unsigned integers from/to PHP using the un/pack functions - simplified right shift of unsinged integers because PHP safes the sing bit on singed integers which leads to bugs or overcomplicated code if you need that bit for others than a sign - if a parameter type-hint or similar functionality will be implemented this type will be very useful, too. Else it will be also useful to make sure you have no negative integer by simply converting to it. What do you think? (Does it worth the expense for a RFC?) Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] unsinged integer
Hi all, I like to create an RFC to add an unsinged integer type for the following purposes: - higher max value - DBs already allow UNSIGNED INT/BIGINT which is a farce to work with in PHP - better support pack/unpack unsigned integers from/to PHP using the un/pack functions - simplified right shift of unsinged integers because PHP safes the sing bit on singed integers which leads to bugs or overcomplicated code if you need that bit for others than a sign - if a parameter type-hint or similar functionality will be implemented this type will be very useful, too. Else it will be also useful to make sure you have no negative integer by simply converting to it. What do you think? (Does it worth the expense for a RFC?) Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unsinged integer
ups (typo + copy past error) It's not my day today! On 22.07.2014 22:21, Rowan Collins wrote: On 22/07/2014 20:55, Marc Bennewitz wrote: I like to create an RFC to add an unsinged integer type +1 for not turning the iron up too high when doing your maths! [https://en.wiktionary.org/wiki/singe] Sorry, it's a common typo, but it made me chuckle that you used it in both the subject and first sentence. More seriously, UnsignedInt might go nicely alongside Andrea's BigInts... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unsigned integer
I mean a new scalar type here On 22.07.2014 22:33, Nikita Popov wrote: On Tue, Jul 22, 2014 at 9:55 PM, Marc Bennewitz p...@marc-bennewitz.de wrote: Hi all, I like to create an RFC to add an unsigned integer type for the following purposes: - higher max value - DBs already allow UNSIGNED INT/BIGINT which is a farce to work with in PHP - better support pack/unpack unsigned integers from/to PHP using the un/pack functions - simplified right shift of unsigned integers because PHP safes the sign bit on signed integers which leads to bugs or overcomplicated code if you need that bit for others than a sign - if a parameter type-hint or similar functionality will be implemented this type will be very useful, too. Else it will be also useful to make sure you have no negative integer by simply converting to it. What do you think? (Does it worth the expense for a RFC?) Could you please further clarify what you mean by type here? If you mean an actual new type (like integers currently are), then I highly doubt this is feasible (implementationally). If you mean something like an UnsignedInt class with overloaded operators, that should be easy to implement. Not sure if we want it in core though. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unsigned integer
Hi Andrea, very nice RFC! You have added the new type internally only. Does it make sense or would it be possible to use one more internal type like ULONG to safe mem/cpu in such cases because bigint/GMP objects are used only on much higher numbers? Marc On 23.07.2014 00:12, Andrea Faulds wrote: On 22 Jul 2014, at 21:21, Rowan Collins rowan.coll...@gmail.com wrote: More seriously, UnsignedInt might go nicely alongside Andrea's BigInts… Bigints kinda remove the need for unsigned ints as you’d be able to use big signed integers of any size. I also really don’t want unsigned int because it makes integer semantics more confusing and you’re splitting integers into two different kinds, unlike bigints which are an implementation detail (there is still just one “integer” type) for the most part. I really, really don’t think this proposal is a good idea. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] directly call a callable
Hi internals, I have opened a PR in april but since that there is no process on it. Please tell me if there are open questions / todos. https://github.com/php/php-src/pull/659 Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Improved logarithm of base 2|10 of standard math function
Hi internals, I have created a PR to improve the base 2 and base 10 of the standard math function log to reduce rounding errors. Internally on log(x, 2) the native C function log2(x) and on log(x, 10) the native C function log10(x) will be called. The PR is open since april without any comments! Please please please someone there to merge this. PS: Because of after this PR the following will be the same in PHP log10(x) === log10(x) the function log10 is needless and could be deprecated/removed. I will create an RFC if this PR was merged. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function
forgotten the link: https://github.com/php/php-src/pull/658 On 14.08.2014 11:43, Marc Bennewitz wrote: Hi internals, I have created a PR to improve the base 2 and base 10 of the standard math function log to reduce rounding errors. Internally on log(x, 2) the native C function log2(x) and on log(x, 10) the native C function log10(x) will be called. The PR is open since april without any comments! Please please please someone there to merge this. PS: Because of after this PR the following will be the same in PHP log10(x) === log10(x) the function log10 is needless and could be deprecated/removed. I will create an RFC if this PR was merged. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function
On 14.08.2014 17:29, Sara Golemon wrote: On Thu, Aug 14, 2014 at 2:44 AM, Marc Bennewitz php@mabe.berlin wrote: forgotten the link: https://github.com/php/php-src/pull/658 On 14.08.2014 11:43, Marc Bennewitz wrote: Hi internals, I have created a PR to improve the base 2 and base 10 of the standard math function log to reduce rounding errors. Internally on log(x, 2) the native C function log2(x) and on log(x, 10) the native C function log10(x) will be called. The PR is open since april without any comments! Please please please someone there to merge this. PS: Because of after this PR the following will be the same in PHP log10(x) === log10(x) the function log10 is needless and could be deprecated/removed. I will create an RFC if this PR was merged. This seems entirely reasonable and would be covered by existing unit tests. No user-impacting effect (beyond being more precise/correct output). I'll push this after my Dr appointment today if nobody has beaten me to it. Nice to see it's merged - thanks! -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function
Sara, shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as PHP-5.6 and shouldn't there an info in the NEWS file? It's currently only merged to master. Marc On 14.08.2014 17:29, Sara Golemon wrote: On Thu, Aug 14, 2014 at 2:44 AM, Marc Bennewitz php@mabe.berlin wrote: forgotten the link: https://github.com/php/php-src/pull/658 On 14.08.2014 11:43, Marc Bennewitz wrote: Hi internals, I have created a PR to improve the base 2 and base 10 of the standard math function log to reduce rounding errors. Internally on log(x, 2) the native C function log2(x) and on log(x, 10) the native C function log10(x) will be called. The PR is open since april without any comments! Please please please someone there to merge this. PS: Because of after this PR the following will be the same in PHP log10(x) === log10(x) the function log10 is needless and could be deprecated/removed. I will create an RFC if this PR was merged. This seems entirely reasonable and would be covered by existing unit tests. No user-impacting effect (beyond being more precise/correct output). I'll push this after my Dr appointment today if nobody has beaten me to it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function
On 15.08.2014 22:39, Andrea Faulds wrote: On 15 Aug 2014, at 19:57, Marc Bennewitz php@mabe.berlin wrote: Sara, shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as PHP-5.6 and shouldn't there an info in the NEWS file? It's currently only merged to master. Marc There might be an argument against adding to 5.4 and 5.5 in that code may now give slightly different results from before, and it’s not really a bugfix as there was no bug. Is the master branch the current 5.6 branch or should it be merged into the PHP-5.6 branch to go in there? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function
On 15.08.2014 22:39, Andrea Faulds wrote: On 15 Aug 2014, at 19:57, Marc Bennewitz php@mabe.berlin wrote: Sara, shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as PHP-5.6 and shouldn't there an info in the NEWS file? It's currently only merged to master. Marc There might be an argument against adding to 5.4 and 5.5 in that code may now give slightly different results from before, and it’s not really a bugfix as there was no bug. Sure, the results can be a little bit different and it's not a bug but the results will be more correct a it was before and there is fully backwards compatible as nobody hears on a very small and rounded value. I don't see any reason to wait for PHP-7 and I also don't see any reason to not integrate it into PHP-5.4 to PHP-5.6 -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Binary String Comparison
Hi internals! I've created a draft RFC and patch to change the behavior of non-strict string to string comparison to be binary safe (as the strict comparison operator does): https://wiki.php.net/rfc/binary_string_comparison On comparing two numeric strings both operands will be equal if the string representation will be the same. On comparing two numeric strings the first operand will be greater if the first not matching byte will be higher. On comparing two numeric strings the first operand will be lower if the first not matching byte will be lower. As a side effect it makes string comparison much faster and force developer to really write what they mean (No need to guess) and to force developers to cast/filter input once which also affects performance. On C-Level the function zendi_smart_strcmp will be unused and marked as deprecated. Thanks, Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 17.08.2014 22:18, Sara Golemon wrote: On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz php@mabe.berlin wrote: I've created a draft RFC and patch to change the behavior of non-strict string to string comparison to be binary safe (as the strict comparison operator does): https://wiki.php.net/rfc/binary_string_comparison If I understand your goal correctly, you seem to want to change a very fundamental (and ancient) behavior of the language even though mechanisms already exist to do what you describe as the changed behavior. What exactly is wrong with ===, strcmp(), etc..? The question isn't What's wrong with ===, strcmp()? but What's wrong with ==, , ?. We have a standard way to compare two operands but currently we do some magic things to solve something that don't need to be solved. If you would like to compare two pears we currently convert the pears into apples and compare two apples and say please use a special function to compare two pears. Why? There is no numeric context to compare two strings numerically. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 18.08.2014 14:53, Pierre Joye wrote: hi, On Mon, Aug 18, 2014 at 2:44 PM, Marc Bennewitz php@mabe.berlin wrote: On 17.08.2014 22:18, Sara Golemon wrote: On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz php@mabe.berlin wrote: I've created a draft RFC and patch to change the behavior of non-strict string to string comparison to be binary safe (as the strict comparison operator does): https://wiki.php.net/rfc/binary_string_comparison If I understand your goal correctly, you seem to want to change a very fundamental (and ancient) behavior of the language even though mechanisms already exist to do what you describe as the changed behavior. What exactly is wrong with ===, strcmp(), etc..? The question isn't What's wrong with ===, strcmp()? but What's wrong with ==, , ?. And the answer is: not strict and why === exists. Non-strict comparison should do conversion to make both operands comparable. It should not convert both operands into a third unrelated type that wasn't mentioned. Btw. The RFC doesn't handle == and === the same because == *do* type-juggling but only if both operands are not on the same type. strcmp() isn't the same behavior as it first converts both operands into a string. Cheers, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 18.08.2014 17:43, Johannes Schlüter wrote:
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Just to make this more fun: Assume $db is PDO then the behavior will
depend on the driver (and for some drivers even at the configuration,
i.e. setting of PDO::ATTR_EMULATE_PREPARES with MySQL) what will happen.
I don't understand exactly what you mean here. This RFC has nothing todo
with DB layer and PDO.
Do you have any example where a DB returns integers differently?
On your example the comparison only fails if the GET-variable is a non
human formed integer means prefixing with a whitespace (but not
suffixing), prefixing with a 0 or formed as a real number or hex.
I'm very sure the changed behavior doesn't open big real life BC issues.
I will run some testsuites on it.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 19.08.2014 05:07, Tjerk Meesters wrote:
On Mon, Aug 18, 2014 at 11:30 PM, Johannes Schlüter
johan...@schlueters.de mailto:johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
johan...@schlueters.de mailto:johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
The question isn't What's wrong with ===, strcmp()? but
What's wrong
with ==, , ?.
We have a standard way to compare two operands but currently
we do some
magic things to solve something that don't need to be solved.
Still it is a key property of the language which we can't
simply change.
Also mind this: All input data are strings and some databases also
return data as string. So code like
if ($_GET['id'] 0)
or
if ($db-fetchRow()[0] == 12)
which is common will break.
Those two cases will actually not be affected, it's strictly
string=string comparisons that's being discussed here.
Meaning that simple code you find everywhere, in every second tutorial
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Not necessarily and certainly not by definition; reasons for failure are
less obvious such as (but not limited to):
0 == 0.0
11 == 11 (but note that 11 == 11 currently yields false)
0 ==
I'm not arguing for or against this behaviour change, but I found it
necessary to clear up some apparent confusion as to what repercussions
this proposal carries.
Another approach of attempting to solve the common issue of comparing
big numbers with '==' is to only enforce string-wise comparison if a
number cast would cause precision loss.
That's a good point, too
johannes
ps. yes, the example might be done nicer and better, it still represents
a common pattern.
--
--
Tjerk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 20.08.2014 12:46, Michael Wallner wrote:
On 20/08/14 11:12, Marc Bennewitz wrote:
On 18.08.2014 17:43, Johannes Schlüter wrote:
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Just to make this more fun: Assume $db is PDO then the behavior will
depend on the driver (and for some drivers even at the configuration,
i.e. setting of PDO::ATTR_EMULATE_PREPARES with MySQL) what will happen.
I don't understand exactly what you mean here. This RFC has nothing todo
with DB layer and PDO.
Do you have any example where a DB returns integers differently?
php -r '$p = new PDO(mysql:user=root); \
$s=$p-prepare(SELECT 1); $s-execute(); \
var_dump($s-fetchAll()); \
$p-setAttribute(PDO::ATTR_EMULATE_PREPARES,false); \
$s=$p-prepare(SELECT 1); $s-execute(); \
var_dump($s-fetchAll());'
array(1) {
[0]=
array(2) {
[1]=
string(1) 1
[2]=
string(1) 1
}
}
array(1) {
[0]=
array(2) {
[1]=
int(1)
[2]=
int(1)
}
}
Thank's for the explanation, but this is nothing that runs into issues
because:
- In case 1 the result number will be a string 1 that is equal with
another string of 1. Only if 1 will be compared to something like
01, 1, 0x1 the result will no longer be the same.
- In case 2 the DB layer already returns an integer and on comparing
this to a string the string will be converted to an integer, too -
nothing changed here by the RFC
To make the example of Johannes fail the DB layer have to return the
integer as string but not formed in a standard human way.
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 20.08.2014 19:50, Ferenc Kovacs wrote: 2014.08.17. 21:59 ezt írta (Marc Bennewitz php@mabe.berlin): Hi internals! I've created a draft RFC and patch to change the behavior of non-strict string to string comparison to be binary safe (as the strict comparison operator does): https://wiki.php.net/rfc/binary_string_comparison On comparing two numeric strings both operands will be equal if the string representation will be the same. On comparing two numeric strings the first operand will be greater if the first not matching byte will be higher. On comparing two numeric strings the first operand will be lower if the first not matching byte will be lower. As a side effect it makes string comparison much faster and force developer to really write what they mean (No need to guess) and to force developers to cast/filter input once which also affects performance. On C-Level the function zendi_smart_strcmp will be unused and marked as deprecated. Thanks, Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Maybe it was already mentionex, but just to make sure: this would fix issues like https://bugs.php.net/bug.php?id=54547 Yes, such comparison issues will go away! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function
On 19.08.2014 00:41, Stas Malyshev wrote: Hi! I opted for master-only on the grounds that while it's an improvement, it's not really a bugfix, and released versions (or versions as near to release as 5.6 is) should be bug-fix only. I know there's an argument for this *being* a bug-fix, but... If a consensus feels it should be merged back I won't object. I think we can have it in 5.6 and 5.5. 5.4 being very close to security-only (with the switch technically being already past due) I'd not merge something that works without the fix back there. 5.5 and 5.6 would be very OK for me :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21.08.2014 17:30, Derick Rethans wrote: On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics Thoughts and questions are appreciated. Thanks! snip And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that Backwards Compatibility is not an issue with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be oh we have a major new version so we can break all the things™. There are two main types of breaking Backwards Compatibility: 1. The obvious case where running things trough ``php -l`` instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple default cases, it's a fricking bug fix too). 2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the Uniform Variable Syntax, that I already `wrote about`_, the current discussion on `Binary String Comparison`_, and now changing the `behaviour`_ on and in a subtle way. These changes are *not okay*, because they are nearly impossible to test for. Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the ``$`` in front of variables to ``£`` is a better change, as it's *immediately* apparent that stuff changed. And you can't get away with But Symfony and ZendFramework don't use this either, as there is so much code out there As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science purity reasons to make things better have little to no meaning for PHP, as it's clearly not designed in the first place. Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. Derick, I'm on you if you say Please think really careful when you suggest to break Backwards Compatibility. It's very important in so much ways. *BUT* you are very unlikely in the cost of the 2 RFCs. First I don't see an comment of you in the Binary String Comparison RFC and I think you should do your misgivings there instead of wring this untopic. Each BC break should be discussed carefully by it's own! Marc **Don't be Evil** cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
On 13.10.2014 02:45, Marco Pivetta wrote: On 12 October 2014 00:47, Andrea Faulds a...@ajf.me wrote: On 11 Oct 2014, at 23:42, Rowan Collins rowan.coll...@gmail.com wrote: func_get_args() and func_num_args(), OTOH, existed solely to support variadics, and anything taking advantage of them being functions rather than a language structure would have to be quite exotic and arcane, so in principle they could, eventually, be removed, but I agree with others that it's far too soon to remove a feature which has been around since 4.0 just becuase 5.6 includes a better alternative. They have some (admittedly limited) use beyond variadics. If you make a function and later make it redirect to another, you can preserve your typehints by using func_get_args() rather than using the … syntax. Can anyone come up with those use-cases? If there is something that `func_get_args()` can do and that can't be done with the code examples that I've pasted before, then I'm missing some bits of information that may make the entire proposal moot. Your implementation of userland_call_user_func doesn't have the same visibility as call_user_func[_array]: http://3v4l.org/lNgub If they're included in the core distribution, then why make them optional at all? If it's just a question of how the functions behave, then surely an included (and C-level) implementation should be sought which has the better behaviour? This matches my own thoughts. There is nothing wrong with these functions. There are just some issues with their implementation. We do not need to get rid of the functions, that would be an absurd overreaction. We should just fix the implementations. The point is removing more API from core and moving it to userland. API implemented in core needs to be maintained by core devs, and is non-transparent to consumers (reflection/debugging/etc). In general, I've always been against any non-language feature that isn't implemented with the language itself, but it's my point of view: as a simple rule of thumb (my rule, many would just say I'm crazy), if it can be implemented in PHP, then don't add it to core or extensions. I would suggest the same deprecation approach for many `array_*` functions, but I assume that I'd only start a giant shitstorm (pardon the wording, but that's the most precise term for that) about performance. Anyway, it's clear that this proposal has short legs, and won't get anywhere in a vote. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
On 13.10.2014 20:48, Marco Pivetta wrote: On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin mailto:php@mabe.berlin wrote: On 13.10.2014 02:45, Marco Pivetta wrote: Your implementation of userland_call_user_func doesn't have the same visibility as call_user_func[_array]: http://3v4l.org/lNgub Interesting: this seems to show that it's even more magic than I expected. Here's just a hacked-together example, just to show that it can be done in userland as well (there may be better ways): http://3v4l.org/QuQM1#v560 Now you have the opposite issue - you are able to call private/protected methods but you shouldn't: http://3v4l.org/rgmh8#v560 Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
On 13.10.2014 22:26, Marco Pivetta wrote: On 13 October 2014 21:18, Marc Bennewitz php@mabe.berlin mailto:php@mabe.berlin wrote: On 13.10.2014 20:48, Marco Pivetta wrote: On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin mailto:php@mabe.berlin wrote: On 13.10.2014 02:45, Marco Pivetta wrote: Your implementation of userland_call_user_func doesn't have the same visibility as call_user_func[_array]: http://3v4l.org/lNgub Interesting: this seems to show that it's even more magic than I expected. Here's just a hacked-together example, just to show that it can be done in userland as well (there may be better ways): http://3v4l.org/QuQM1#v560 Now you have the opposite issue - you are able to call private/protected methods but you shouldn't: http://3v4l.org/rgmh8#v560 Good catch, but I'm not trying to build a complete solution in a gist: if I do, then I'll just make a lib and include all existing `.phpt` tests related to `call_user_func`, no? :-) Just a revision of the userland version, for fun: http://3v4l.org/6IKKl#v560 Sure, but it shows that it's not a simple two-liner to have a well working solution in userland. The more complicated it is the more error-prone it will be and btw. slow down. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
[PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
... like the hidden array element: http://3v4l.org/6uFqf ... like the hidden object property: http://3v4l.org/RPJXH Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
On 14.10.2014 09:25, Stas Malyshev wrote:
Hi!
... like the hidden array element: http://3v4l.org/6uFqf
... like the hidden object property: http://3v4l.org/RPJXH
The issue seems to be that array lookup always looks for numeric results
when looking for numeric-like keys. But when adding property, the
numeric check is not done since properties are not supposed to be
numeric. Thus, when converting the object to array, the property named
123 becomes inaccessible, because in array it is supposed to be under
number 123.
We could, of course, add numeric checks to properties, but it would slow
things down only to serve very narrow use case with hardly any legit
uses. We could also rewrite hashtable with numeric keys instead of
string keys when doing conversion, but again that would be significant
slowdown for a very rare use case. Not sure it's worth it.
Please correct me if I'm wrong but object properties should be strings
in all cases.
So all properties set should be converted to string means the following
should be equal but isn't and I don't see any performance issues forcing
strings here:
|$obj = (object)array('123' = '456');
var_dump($obj);
var_dump($obj-{'123'}); // ||Notice: Undefined property: stdClass::$123|
|var_dump($obj-{123});| |// ||Notice: Undefined property:
stdClass::$123|
For the case of object to array conversion a numeric check could be very
improved by simply check if the first character between 0-9 before
starting the complete numeric check. That would be very fest and it
produces right results. It's poor to say ... very narrow use case with
hardly any legit uses ... in programming languages. In my opinion the
right result have to be the first goal and performance optimization is
something to keep in mind but should never produce wrong results.
Marc
Re: [PHP-DEV] [RFC] Safe Casting Functions
On 22.10.2014 10:37, Bob Weinand wrote:
I know we have that already discussed a lot now, but I’d like to expose my
points on the return value here:
I imagine code like (supposing that we ever will have scalar typehints):
function acceptsInt (int $i = null) {
if ($i === null) {
$i = 2 /* default value */;
}
/* do something with $i */
}
NULL isn't a pointer for a default value - it's simply a type with no
value - no more - no less.
From your example: why do you accept NULL if you need a integer default
value?
function acceptsInt (int $i = 2) { ...
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
I really like the strictness of this casting rules except of 010 will be a valid integer / float. As of you don't allow 0x and trailing white spaces as valid numbers and don't allow floating like syntax as integers even if it result in mathematical integer. Allowing prefixed 0 as valid numbers results in a small data loss (010 !== to_string(to_int(010))), is simple to address in user land with ltrim(010, 0) (Same argument as trailing whitespace) and collides with octal notation (010 !== to_int(010)) Marc On 21.10.2014 00:57, Andrea Faulds wrote: Good evening, I am presenting a new RFC to add a set of three functions to do validated casts for scalar types: https://wiki.php.net/rfc/safe_cast Please read it. 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] [RFC] Safe Casting Functions
You addresses data loss on convert float to int. Do you also address data loss on int to float? |to_float(||9223372036854774784) - pass |as it results in 9223372036854774784 |to_float(|||9223372036854774785|) - |failas it results in 9223372036854774784 | Marc | On 23.10.2014 21:40, Marc Bennewitz wrote: I really like the strictness of this casting rules except of 010 will be a valid integer / float. As of you don't allow 0x and trailing white spaces as valid numbers and don't allow floating like syntax as integers even if it result in mathematical integer. Allowing prefixed 0 as valid numbers results in a small data loss (010 !== to_string(to_int(010))), is simple to address in user land with ltrim(010, 0) (Same argument as trailing whitespace) and collides with octal notation (010 !== to_int(010)) Marc On 21.10.2014 00:57, Andrea Faulds wrote: Good evening, I am presenting a new RFC to add a set of three functions to do validated casts for scalar types: https://wiki.php.net/rfc/safe_cast Please read it. Thanks! -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] [RFC] Safe Casting Functions
On 24.10.2014 01:53, Andrea Faulds wrote: On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote: You addresses data loss on convert float to int. Do you also address data loss on int to float? |to_float(||9223372036854774784) - pass |as it results in 9223372036854774784 |to_float(|||9223372036854774785|) - |failas it results in 9223372036854774784 Floats aren’t expected to be precise, so I don’t see why this shouldn’t pass. It’s a loss of data, sure, but merely of precision, which is expected here. The reason I have to_int fail is because float overflow to int completely mangles your input. ... It’s a loss of data ... And that is the point! If you don't care about loss of data we have more than enough functions including default casting (float) operator to cast to float. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
On 24.10.2014 20:13, Andrea Faulds wrote: On 24 Oct 2014, at 19:06, Marc Bennewitz php@mabe.berlin wrote: On 24.10.2014 01:53, Andrea Faulds wrote: On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote: You addresses data loss on convert float to int. Do you also address data loss on int to float? |to_float(||9223372036854774784) - pass |as it results in 9223372036854774784 |to_float(|||9223372036854774785|) - |failas it results in 9223372036854774784 Floats aren’t expected to be precise, so I don’t see why this shouldn’t pass. It’s a loss of data, sure, but merely of precision, which is expected here. The reason I have to_int fail is because float overflow to int completely mangles your input. ... It’s a loss of data ... And that is the point! If you don't care about loss of data we have more than enough functions including default casting (float) operator to cast to float. Floats are special, they are not expected to be precise. If we reject this, then perhaps we should also reject 0.1, because it can’t be precisely represented by a float? It's a difference casting string to float or int to float. Floats are often used to make sure an argument is a valid number but this results in data loss incl. on internal functions. take this simple example: echo number_format(9223372036854774785); -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
On 24.10.2014 20:54, Andrea Faulds wrote: On 24 Oct 2014, at 19:52, Marc Bennewitz php@mabe.berlin wrote: Floats are special, they are not expected to be precise. If we reject this, then perhaps we should also reject 0.1, because it can’t be precisely represented by a float? It's a difference casting string to float or int to float. Floats are often used to make sure an argument is a valid number but this results in data loss incl. on internal functions. You’re not using the right function, then. That's not the point! We already have casting functions what will work in all cases even on data loss. I thought you are proposing safe casting functions with no data loss. If not, what are you proposing ? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disallow non-static method calls with self/static in PHP 7
On 12.10.2014 12:10, Nikita Popov wrote:
On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll p...@tutteli.ch wrote:
Hey,
I just stumbled over a method call of a non-static method with self and
was asking myself again, why does PHP support
this behaviour. An example to outline what I am writing of:
class A{
function foo(){
self::bar();
}
function bar(){}
}
IMO it should not be allowed to call non-static methods with self or
static. Sure, it is just a small detail but for
someone who starts learning PHP it is an unnecessary supplement.
Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like to
know what you think about it and if someone
has a good reason why it is allowed nowadays then please help me out.
There's a common misconception that ::foo() denotes a static method call in
PHP. What it actually does is a *scoped* call (which is why :: is called
the scope resolution operator and not the static access operator).
What :: essentially does is give you the ability to call the implementation
of a method in a particular class. A common application is the use of
parent::foo() which will not call your implementation of foo(), but the one
found in the parent class. Similarly you can use A::foo() to target a
particular class that is even further up in the inheritance hierarchy
(like, the grandparent-class). You can also call call a class that is
completely outside your inheritance hierarchy, but that's deprecated since
PHP 5.6 and will hopefully be removed in PHP 7.
Theoretically spoken, the :: operator would be changeable to static
access operator.
Would that change any behavior outside of calling non static method
statically?
Would that open the possibility to register static methods in another
function table as object methods?
So e.g. it would be possible to have public static __call() instead of
public static __callStatic().
Nikita
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
public static function factory($name) : AdapterInterface {
$class = 'MyNamespace\Adapter\' . $name;
return $class();
}
}
Marc
Am 25.11.2014 um 18:08 schrieb Levi Morrison:
Dear Internals,
As you may remember, I closed the voting on the return types
[RFC](https://wiki.php.net/rfc/returntypehinting) because of a design
flaw that was found during the voting process. The purpose of this
discussion thread is to explain the various options for checking
return type compatibility with parent methods that I think are viable,
to show some of the benefits and drawbacks of each option, and to
solicit feedback on which options you prefer and why. As such, it's
much longer than a normal message I would send.
The following code demonstrates the design flaw mentioned above:
class A {
function foo(): B { return new B; }
}
class B extends A {
function foo(): C { return new C; }
}
class C extends B {}
$b = new B;
$c = $b-foo();
I've also used it because it can adequately show the differences in
how each of the following options work:
1. Do covariant return types; check them at definition time
2. Do covariant return types; check them at runtime
3. Do invariant return types; check them at definition time
Option 1: Covariant return types with definition time checking
--
This is the option that is currently implemented in my pull request.
This option catches all return type variance issues whether code is
used or not; if it got included it is checked. This means return type
variance issues can't bite you later.
When class B is defined, the engine needs to check that the method
`B::foo` has a compatible return type with `A::foo`, in this case that
equates to checking that C is compatible with type B. This would
trigger autoloading for C but it will fail in this case because C is
defined in the same file. Note that there are ways we could fix this
issue, but not reliably because of conditionally defined classes
(defining classes in if blocks, for example) and other such dynamic
behavior. Even if we could fix this issue, there is still an issue if
A, B and C were defined in separate files and then included. You
couldn't require them in any order for it to work; you would have to
autoload.
Option 2: Covariant return types with runtime checking
--
This option would do the variance check when the method is used (or
potentially when the class is instantiated, or whichever comes first).
Regardless of the exact details of how this method is implemented, the
above code would work because the first time class B is used in any
way occurs after C is defined. This would also work if you separated
them out into different files
This option would be slower than option 1, but cannot quantify it
because it is not yet implemented. I suspect there would be a way to
cache the result of the variance check to not have to do it on every
instantiation or invocation, so this may be negligble.
This option has the drawback that inheritance problems can exist in
the code and won't be discovered until the code is ran. Let me repeat
that to make sure that everyone understand it: if you have return type
variance errors in your code, they would not be detected until you try
to use the class or method.
Option 3: Invariant return types with definition time checking
--
This means that the declared types must *exactly match* after
resolving aliases such as parent and self. The advantage of this
option is that the inheritance check can be done at definition time in
all cases without triggering an autoload. As such it is a bit simpler
to implement and is slightly faster to do so. The obvious downside is
that it can't support covariant return types.
---
Note that C++ and Java (and most modern languages) support covariant
return types, but C# supports only invariant return types.
Which of these methods do you prefer the most, and which do you prefer
the least, and why?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Idea: immutable class / object
Hi internals,
In OOP it's a sometimes a common issue to know the state of an object
and to know if it was changed respectively it it can change state.
We already have such objects like DateTImeImmutable and new proposed
objects like UString also introduce immutable objects.
I think it would be really helpful to see this kind of issue addressed
in a standardized way:
if you approve with this I would write down a more structured RFC.
Now see the following code snipped:
?php
immutable class MyImmutableClass {
public static $staticProperty = 'private static';
public $ts;
public $obj;
public function __construct($obj = null) {
$this-ts = time();
$this-setObj($obj);
}
public function getTimestamp() { return $this-ts; }
public function getObj() { return $this-obj; }
public function setObj($obj) { $this-obj = $obj; }
}
// initialize
$obj = new DateTImeImmutable();
$obj = new MyImmutableClass($obj);
// check if immutable
var_dump(MyImmutableClass::immutable);
var_dump($obj::immutable);
// read properties
var_dump($obj-ts, $obj-obj);
var_dump($obj-getTimestamp(), $obj-getObj());
// ERROR: Immutable objects can not contain mutable properties
$obj = new MyImmutableClass(new stdClass);
// ERROR: Immutable objects can not be changed after initialization
$obj = new MyImmutableClass();
$obj-setObj($obj);
$obj-obj = $obj;
// ERROR: It's not allowed to change immutable variables
MyImmutableClass::$staticProperty = 'new value';
?
Because of for immutable objects it's not allowed to set an mutable
object as property
you can be sure the object's state will be consistent. That's the main
difference from
marking all properties readonly or similar functionalities.
Additionally it's simple to test if an class/object is immutable and
document it for free.
Downside: New Keyword immutable
/http://dict.leo.org/#/search=adv.searchLoc=0resultOrder=basicmultiwordShowSingle=on/
Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
public static function factory($name) : AdapterInterface {
$class = 'MyNamespace\Adapter\' . $name;
return $class();
}
}
It seems that I did not explain this clearly enough; I apologize. The
variance has to do with the declared type in the function signature
when inheritance is involved, not the type of the value returned by
the function.
For instance, under any of the three options this code will work just fine:
class Foo {}
class Goo extends Foo {}
class FooFactory {
function create(): Foo { return new Goo(); }
}
As long as the return value from FooFactory::create returns Foo or a
subtype of Foo (such as Goo), then it will work.
The variance that is under discussion in this thread is about the
declared return type in the signature:
class GooFactory extends FooFactory {
function create(): Goo {}
}
In this case, GooFactory::create() declares a return type of Goo,
which is a subtype of Foo [the return type of the inherited method
FooFactory::create()]. This is a covariant return type.
If we choose option 3, the only possible return type for
GooFactory::create is Foo.
Hopefully this clarifies the issue.
Yes it does - thank you for explanation - my mistake :/
Option 3 is a no go not from OOP perspective and from consistency pov as
we already allow this in type-hint:
class FooFactory {
function create(Foo $foo): Foo { return $foo; }
}
class GooFactory extends FooFactory {
function create(Goo $goo): Goo { return $goo; }
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
Am 25.11.2014 um 23:13 schrieb Marc Bennewitz:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2)
because
one of the use cases for return type-hint are factories and such
often do
instantiation in base of unknown string values:
class MyFactory {
public static function factory($name) : AdapterInterface {
$class = 'MyNamespace\Adapter\' . $name;
return $class();
}
}
It seems that I did not explain this clearly enough; I apologize. The
variance has to do with the declared type in the function signature
when inheritance is involved, not the type of the value returned by
the function.
For instance, under any of the three options this code will work just
fine:
class Foo {}
class Goo extends Foo {}
class FooFactory {
function create(): Foo { return new Goo(); }
}
As long as the return value from FooFactory::create returns Foo or a
subtype of Foo (such as Goo), then it will work.
The variance that is under discussion in this thread is about the
declared return type in the signature:
class GooFactory extends FooFactory {
function create(): Goo {}
}
In this case, GooFactory::create() declares a return type of Goo,
which is a subtype of Foo [the return type of the inherited method
FooFactory::create()]. This is a covariant return type.
If we choose option 3, the only possible return type for
GooFactory::create is Foo.
Hopefully this clarifies the issue.
Yes it does - thank you for explanation - my mistake :/
Option 3 is a no go not from OOP perspective and from consistency pov
as we already allow this in type-hint:
class FooFactory {
function create(Foo $foo): Foo { return $foo; }
}
class GooFactory extends FooFactory {
function create(Goo $goo): Goo { return $goo; }
}
OK HHVM allows it - we also allow it but trigger an E_STRICT error
@see http://3v4l.org/UhtOb
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Idea: immutable class / object
Thoughts ?
Am 25.11.2014 um 22:26 schrieb Marc Bennewitz:
Hi internals,
In OOP it's a sometimes a common issue to know the state of an object
and to know if it was changed respectively it it can change state.
We already have such objects like DateTImeImmutable and new proposed
objects like UString also introduce immutable objects.
I think it would be really helpful to see this kind of issue addressed
in a standardized way:
if you approve with this I would write down a more structured RFC.
Now see the following code snipped:
?php
immutable class MyImmutableClass {
public static $staticProperty = 'private static';
public $ts;
public $obj;
public function __construct($obj = null) {
$this-ts = time();
$this-setObj($obj);
}
public function getTimestamp() { return $this-ts; }
public function getObj() { return $this-obj; }
public function setObj($obj) { $this-obj = $obj; }
}
// initialize
$obj = new DateTImeImmutable();
$obj = new MyImmutableClass($obj);
// check if immutable
var_dump(MyImmutableClass::immutable);
var_dump($obj::immutable);
// read properties
var_dump($obj-ts, $obj-obj);
var_dump($obj-getTimestamp(), $obj-getObj());
// ERROR: Immutable objects can not contain mutable properties
$obj = new MyImmutableClass(new stdClass);
// ERROR: Immutable objects can not be changed after initialization
$obj = new MyImmutableClass();
$obj-setObj($obj);
$obj-obj = $obj;
// ERROR: It's not allowed to change immutable variables
MyImmutableClass::$staticProperty = 'new value';
?
Because of for immutable objects it's not allowed to set an mutable
object as property
you can be sure the object's state will be consistent. That's the main
difference from
marking all properties readonly or similar functionalities.
Additionally it's simple to test if an class/object is immutable and
document it for free.
Downside: New Keyword immutable
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Idea: immutable class / object
Am 27.11.2014 um 20:47 schrieb Levi Morrison:
Am 25.11.2014 um 22:26 schrieb Marc Bennewitz:
Hi internals,
In OOP it's a sometimes a common issue to know the state of an object and
to know if it was changed respectively it it can change state.
We already have such objects like DateTImeImmutable and new proposed
objects like UString also introduce immutable objects.
I think it would be really helpful to see this kind of issue addressed in
a standardized way:
if you approve with this I would write down a more structured RFC.
Now see the following code snipped:
?php
immutable class MyImmutableClass {
public static $staticProperty = 'private static';
public $ts;
public $obj;
public function __construct($obj = null) {
$this-ts = time();
$this-setObj($obj);
}
public function getTimestamp() { return $this-ts; }
public function getObj() { return $this-obj; }
public function setObj($obj) { $this-obj = $obj; }
}
// initialize
$obj = new DateTImeImmutable();
$obj = new MyImmutableClass($obj);
// check if immutable
var_dump(MyImmutableClass::immutable);
var_dump($obj::immutable);
// read properties
var_dump($obj-ts, $obj-obj);
var_dump($obj-getTimestamp(), $obj-getObj());
// ERROR: Immutable objects can not contain mutable properties
$obj = new MyImmutableClass(new stdClass);
// ERROR: Immutable objects can not be changed after initialization
$obj = new MyImmutableClass();
$obj-setObj($obj);
$obj-obj = $obj;
// ERROR: It's not allowed to change immutable variables
MyImmutableClass::$staticProperty = 'new value';
?
Because of for immutable objects it's not allowed to set an mutable object
as property
you can be sure the object's state will be consistent. That's the main
difference from
marking all properties readonly or similar functionalities.
Additionally it's simple to test if an class/object is immutable and
document it for free.
Downside: New Keyword immutable
What I think is more useful is C++'s const, which basically makes any
structure immutable when you need it. However, I don't think it's
worth going through the effort to bring this to PHP, as you would have
to add checks for preventing state changes in many places at runtime.
Are you sure there are so much places and runtime checks required for
immutable classes?
It's only needed to test on immutable objects and such objects doesn't
do it as it's not possible to do.
I think of flag ZEND_ACC_IMMUTABLE + simply switch the internal default
function used to write properties to an object but I don't have enough
knowledge about the engine.
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Static functions Vs Nonstatic functions
Please read :
http://grokbase.com/t/php/php-internals/14acs23cpe/disallow-non-static-method-calls-with-self-static-in-php-7#20141026ct1np9k82bte2m9k9rtmq1c2jr
Am 28.11.2014 um 20:29 schrieb Carlos Rodrigues:
PHP has evolved a lot in recent years but we still can't have a static and
a nonstatic function with the same name:
class A {
function bla() { echo 'normal'; }
static function bla() { echo 'static'; }
}
A::bla();
## ERROR: Cannot redeclare A::bla()
And also PHP supports calling static functions as if they were not static:
class B {
static function bla() { echo 'how come it works'; }
}
$object = new B;
$object-bla();
It confuses programmers that came from other languages, prevent APIs from
having meaningful names on static methods and have no other benefit than
supporting PHP 4 code.
I'd appreciate if anyone with sufficient knowledge/influence helped me
suggest this change to the maintainers.
IMHO, static and nonstatic functions should be stored in different
places. And if someone relies on this, one should use magic methods __call
and __callStatic instead.
Thanks for your time and patience,
Carlos Rodrigues
car...@jp7.com.br
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()
Am 28.11.2014 um 21:21 schrieb Levi Morrison: Won't `$obj1 === $obj2` work for you ? This works if you have two objects which are easily accessible in the same scope. Not that it can not be done this way, but it may require jumping through hoops to get two object references into the common scope where you can compare them. If you can get their hashes to the same place, you can get the object to the same place. Big -1 from me. This given example sounds wired to me, too. But to have a unique ID for objects sound like a very good idea and would solve the object as array key issue. I'm sure it's not as simple as the function prototype explained in this thread previously. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] persistent zval
Hi all, Is it possible to make a zval persistent? Currently I only found persistent resources or internal references used in objects. It would be very great for some userland applications to make a value persistent whatever type it is. Like the internal global persistent_list but this one is used for persistent resources and I don't see how to use this one for zval's directly. Additionally it's used internally with unknown hashes so it could be dangerous to export it to userland. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] persistent zval
Am 09.12.2014 um 20:03 schrieb Sara Golemon: On Tue, Dec 9, 2014 at 10:58 AM, Marc Bennewitz dev@mabe.berlin wrote: Is it possible to make a zval persistent? Nope. Why? There is a reference counter, which should be increased on put a value into persistence and on removing a value from persistence decrease it. So the GC could handle unreferenced zvals. Example: persist_set($key, $value); persist_get($key); persist_has($key); persist_list(); // list of persistent values -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] persistent zval
Am 10.12.2014 um 09:53 schrieb Stanislav Malyshev: Hi! Why? There is a reference counter, which should be increased on put a value into persistence and on removing a value from persistence decrease it. So the GC could handle unreferenced zvals. Because memory which is allocated by the engine is freed at the end of the request. You could copy the memory values but by then unless your zvals are pretty simple you'll be pretty close to what the serializer does, so no really big win there. The only advantage would be that when you use it, if you're really careful, then you can use the data without reallocating memory and freeing it. But it's not just putting a flag/refcount on it, it requires some copying before that and some careful setting of the refcounts too. So in theory, it can be done at least for scalars and arrays (objects would be a problem since they need class, and what if the class changed?) but it's not trivial. Thanks for the explanation! I'll experiment with it for scalars as extension. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP6 artifact - binary strings
Hi all, Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can define binary strings but such definitions haven't any effect. So what we can define is the following: $str = str; $bin = bb\0i\0n; $str2bin = (binary)$str; One of the biggest issue is that currently ALL strings will be handled as ASCII-7 compatible strings on type-juggling but they aren't. It would be very appreciated if PHP could respect such binary declaration: * use binary string comparison on compare a binary string to any other string * don't convert binary strings into integers on array keys * allow bitwise operators on binary strings without casting to integer I don't wont to open such unicode nightmare as it was planned for PHP-6! In my opinion the above operator changes are enough and therefore internal functions doesn't need to be changed in the first place. The only changes *could* be done to functions reading/parsing data to be auto marked binary like: unpack, stream reading functions opened with fopen + b ... I don't have enough zend experience and therefore I would like to know how complicated it would be. Thoughts? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Skipping parameters take 2
Am 14.01.2015 um 20:21 schrieb Adam Harvey: On 14 January 2015 at 11:15, Marc Bennewitz dev@mabe.berlin wrote: But I think adding default as new keyword is a big BC break! Default already is a keyword: http://php.net/switch. There's no BC break. OMG you are right - my fault I personally also don't like it and asked myself why can't the parameter simply skipped? That was in the original proposal, but counting commas is pretty lousy if you're skipping more than one or two parameters. Having a keyword makes it more readable. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Andrea, I have some notes about this RFC from a users POV with only little knowledge about internals. I didn't read 100% of the theads of this RFC so I'm sorry if some notes of this email was already discussed. 1. Inconsistencies of ZPP and explicit casts In my opinion it should be the same if you call a function in weak type mode and calling a function in strict type mode with explicit cast. But that would require to remove inconsistencies of ZPP and explicit casts. 2. Only one choice for the language In my opinion scalar types should be hinted strict and the caller of an API have to be sure to pass the right types. The caller have to know about the function he calls and he already should know what the function expects. This is the point were the caller have to know the type of an expected argument and he should know his own types. So he is the one how can pass the variable or make an explicit type cast. To do so see [1] 3. Reserved words I don't like it adding so much reserved words. As I understand it correctly the reservation is because of naming collisions on type-hints with scalars and classes/interfaces. Why not adding these types as classes (marked final and not allowed to be initialized for know)? Than you can use the already existing standards of classes as type-hints. This would allow you using your own class of a different namespace with the same name and would reduce BC break drastically. The only consequence would be that you have to reference the root namespace or import (use) the classes of the root namespace to use the type-hints. As sugar it should be possible to use inheritance and polymorphism to better hint what you really need. E.g.: class Integer extends Scalar implements Numeric 4. Only one naming I dislike the proposed aliases. The type names should be defined once without aliases and the manual and error massages should be changed to be consistent. Because of PHP internally already allows different names this should persist to be BC safe but should be reviewed and documented what is the real type name and what are aliases. The aliases could be deprecated in another RFC. Btw. The type float is used also as double and real. I don't see if these aliases are supported in your RFC or not. Marc Am 14.01.2015 um 01:16 schrieb Andrea Faulds: Good evening, I’ve made some quite significant changes to my Scalar Type Hints RFC, and bumped its version to 0.2. Here: https://wiki.php.net/rfc/scalar_type_hints This is a new thread because I’ve made a significant revision to the RFC, so it’d be sensible to separate discussion of the updated RFC from the v0.1 RFC. Please tell me your thoughts. 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] [RFC] Skipping parameters take 2
Hi Stas,
I really like this RFC. It makes it simple to use defined defaults
without the need to know about them of to updated.
But I think adding default as new keyword is a big BC break!
I personally also don't like it and asked myself why can't the parameter
simply skipped?
function foo ($a='a', $b='b') {}
foo();
foo($a);
foo(, $b);
foo($a,);
foo(,);
Is it possible to use the default parameter on inheritance?
class Bar {
function foo($a='a', $b='b') {}
}
class Baz extends Bar {
function foo($a=default, $b=default) {
// do something
parent::foo($a, $b);
}
}
Marc
Am 02.09.2013 um 09:17 schrieb Stas Malyshev:
Hi!
I've finally took some time to revive the skipping parameter RFC and
patch. For those who doesn't remember what it is please see:
https://wiki.php.net/rfc/skipparams
TLDR version:
The idea is to allow skipping parameters in function with optional
arguments so that this:
function create_query($where, $order_by, $join_type='INNER', $execute
= false, $report_errors = true)
can be called like this:
create_query(deleted=0, name, default, default,
/*report_errors*/ true);
Instead of trying to remember what the defaults are.
The patch is here:
https://github.com/php/php-src/pull/426
Any comments or feedback on the RFCs and the code are welcome,
especially pointing out the cases where it may not work (which means we
need more phpt's there :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Am 15.01.2015 um 20:45 schrieb Marcio Almada:
Hi,
I would like to call everyone's attention, specially people
contributing directly to this RFC series, to what S.A.N just said:
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
Maybe it makes sense to put this option on the ballot if it passes a vote,
it will be possible to put an end to the discus?
This idea has been **so recurrent** and yet systematically ignored by RFC
owners. Why? I think that we need to baby step and try to approve coercive
type declarations first and decide upon a possible stricter type check
later:
How a bout a reboot of what ircmax...@php.net already started in
https://wiki.php.net/rfc/parameter_type_casting_hints for v0.3?
PS: Please, let's not fall into the mindset of if v0.2 is not a good idea
then v0.1 instantly becomes more acceptable, we still have time to try
some alternatives.
A function only defines the arguments and types it requires and not
where the arguments comes from. Casting is part of Where the arguments
comes from
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Am 14.01.2015 um 23:39 schrieb Andrea Faulds:
Hi Marc,
On 14 Jan 2015, at 19:01, Marc Bennewitz dev@mabe.berlin wrote:
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the same if you call a function in weak type mode
and calling a function in strict type mode with explicit cast.
But that would require to remove inconsistencies of ZPP and explicit casts.
Explicit casts and implicit casts have different behaviour, and that is
definitely a good thing. Implicit casts can and should fail if the conversion
isn’t sensible. Explicit casts aren’t supposed to fail.
That's a big problem for the strict type mode because of you have to
explicit cast to pass function signature which would result in a much
unsafer behavior were you originally wont a strict behavior. The only
way to be safe would be to use extra function calls for casting.
2. Only one choice for the language
In my opinion scalar types should be hinted strict and the caller of an API
have to be sure to pass the right types. The caller have to know about the
function he calls and he already should know what the function expects. This is
the point were the caller have to know the type of an expected argument and he
should know his own types. So he is the one how can pass the variable or make
an explicit type cast.
This is all very well and good, and strict typing has its advantages, but there
are a lot of people who do *not* want to have to deal with a strictly-typed API.
It's only a personal feeling for scrict typing but it requires casting
to be fixed.
But I have to agree with that casting is part of the caller with or
without this choice.
The library author only defines the type he requires but the caller is
the one have have to do so. Week typing in this case only helps the
caller to automatically cast.
3. Reserved words
I don't like it adding so much reserved words.
This doesn’t add any reserved words. It prevents the usage of some names for
class names.
Preventing usage of some names means the same as reserved names at least
in the contest of class names.
As I understand it correctly the reservation is because of naming collisions on
type-hints with scalars and classes/interfaces.
Why not adding these types as classes (marked final and not allowed to be
initialized for now)?
Because then you’d have to do this at the top of every single file:
use php\typehint\int;
use php\typehint\float;
use php\typehint\string;
use php\typehint\bool;
Considering how much people seem to dislike the idea of using declare() for
strict typing, I can see how poorly that would go down.
Such types should be on the root namespace. So the only difference would
be a backslash and only if you are within a namespace.
And to reaped myself you can do vary useful:
// internal pseudo code
class Scalar {}
interface Numeric {}
class Integer extends Scalar implements Numeric {}
class Float extends Scalar implements Numeric {}
class String extends Scalar {}
class Array implements Traversable {}
// users code
function increment(numeric $num) { return $num + 1; }
function incrementInt(integer $int) { return $int + 1; }
function incrementFloat(float $float) { return $float + 1; }
// in namespace
function increment(\numeric $num) { return $num + 1; }
function incrementInt(\integer $int) { return $int + 1; }
function incrementFloat(\float $float) { return $float + 1; }
More importantly, this would be inconsistent with our existing type hints like
array and callable.
It would only be inconsistent if you don't think it through end but sure
it's more work. I have no idea how much.
On calling a function in week mode one or more magic methods could be
used to add auto cast behavior like:
public function __toInt();
public function __toFloat();
public function __toString(); // it will be called already
public function __toArray(); // Not part of this RFC
public function __toInstanceOf($name); // Will be called if no one of
the other pass
4. Only one naming
I dislike the proposed aliases. The type names should be defined once without
aliases and the manual and error massages should be changed to be consistent.
In an ideal world we would only have the short or long form, sure. But this
isn’t an ideal world, and PHP doesn’t have compile-time validation of type
hints. It would be too easy to write foo(integer $bar) and miss that it is
broken if the function isn’t called.
Please let us make PHP more ideal ;)
Your argument is nonsense. As long as you never test your (unittest or
manual) you can't be sure to work well. The same argument could pass for
current type-hinting. If that argument is serious you have to eg.
automatically fix type errors in class names.
Btw. IDEs already warn if you use something undeclared project wide.
I don’t think having both int and integer is really a problem. It’s not going
to cause confusion, they are obviously the same type. Coding style guides will
mandate
Re: [PHP-DEV] [RFC] Skipping parameters take 2
Hi Robert
Am 16.01.2015 um 11:04 schrieb Robert Stoll:
Hi Stas,
-Ursprüngliche Nachricht-
Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
Gesendet: Mittwoch, 14. Januar 2015 21:26
An: Marc Bennewitz; internals@lists.php.net
Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2
Hi!
Is it possible to use the default parameter on inheritance?
class Bar {
function foo($a='a', $b='b') {}
}
class Baz extends Bar {
function foo($a=default, $b=default) {
// do something
parent::foo($a, $b);
}
}
It's not part of the original proposal, and I'm not sure how easy it would be
to implement, but it sounds like a nice
extension, I didn't think about it. Since the RFC is already in vote, I won't
change it now, but I'll look into if
it's possible to do
it, and if the RFC is accepted, and it proves possible, I'll propose it
separately.
--
Stas Malyshev
smalys...@gmail.com
This would be quite a nice feature, even if this RFC does not pass. Just as
hint, there are ambiguous case which need to
be considered:
interface A{
function foo($a=1);
}
interface B{
function foo($a=hi);
}
class C implements A, B{
function foo($a=default){} //what would be the default value?
}
Cheers,
Robert
The default value have be the one of the parent.
if there is no parent you have the following options:
* Syntax error (I prefer)
* If defined use from interface
* If ambiguous:
* Syntax error
* Choose one (bad in my opinion)
Marc
Re: [PHP-DEV] Static Closures and PHP 7
Am 20.01.2015 um 18:58 schrieb Levi Morrison:
Internals,
Last year I fixed the behavior of closures in a few regards, which
were included in PHP 5.5.14 and 5.6 (unsure on exact version):
- Static closures properly use late-static binding on `static::`
calls from inside static methods.
- Non-static closures in static methods are automatically promoted
to static closures
The first item is undoubtably a bug-fix (see http://3v4l.org/lVenA for
an example).
The second item, however, is a bit more questionable. Take as an
example this code: http://3v4l.org/YMYeu (located at bottom of email
as well). When in global scope using an anonymous function with a
$this-ptr does not error, but when we are in a static method there is
a warning at bind-time and a fatal when the method is called.
Before my changes I could have said this was a bug with confidence.
After my change, however, it means that the closure is implicitly
static and therefore cannot use a $this pointer. My patch didn't break
anything, but allowed people to use late static binding in non-static
closures inside of static methods (I recommend reading that sentence
again).
Logically, I am surprised by this behavior. I would think that
anything permissible for a closure in global scope is also permissible
for a closure in static scope.
What do you guys and gals think?
It should indeed have the same object behavior as closures in global scope.
Before bind: Fatal error: Using $this when not in object context
After bind: valid
But static:: and self:: should work the same as on static closures.
?php
class A {
function hi() {
return hello;
}
}
// in global scope
$f = function() {
return $this-hi(); // no warnings
};
$a = new A();
$g = $f-bindTo($a); // no warnings
echo $g(), PHP_EOL; // no warnings
class B extends A {
// in a static function
static function make() {
return function() {
return $this-hi(); // fatal error when called
};
}
}
$h = B::make();
$i = $h-bindTo($a); // warning
echo $i(), PHP_EOL; // fatal error
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Skipping parameters take 2
Am 19.01.2015 um 19:48 schrieb Adam Harvey: On 17 January 2015 at 18:04, Andrea Faulds a...@ajf.me wrote: For consistency with list(), we could also just put nothing: foo($bar, , $baz); Which is like: list($bar, , $baz) = $arr; Thoughts? That was Stas's original, original proposal way back when. I argued then for having default as a placeholder, and still would today — in the case where a function with, say, ten optional parameters[0] is being called and eight of them should be the default, I think it's a bit rough for somebody inheriting that code to have to count commas. Having a token increases readability, IMO, and costs us nothing except a few keystrokes, which isn't going to break the camel's back in a language that requires function each time you declare a function. Adam [0] Yes, that's probably poor API design. You and I both know someone will do it, though. :) Pros Cons _Simply skipping the argument out:_ pro: - same syntax as skipping entries used by `list` con: - hard to read and to differ from mistakes - not an option for inheritance _Using the keyword `default`:_ pro: - better to read and to differ from mistakes - usable on inheritance con: - different syntax as `list` - not possible as alternative syntax for `list` as it has no default naming _Using a special character:_ pro: - better to read and to differ from mistakes - usable on inheritance - possibly an alternative syntax for `list` (for consistency) con: - different syntax as `list` - Not a good character found for it, yet _Named Parameters:_ pro: - readability (If caller is not required to call as assoc array) - not an option for inheritance con: - paramter skipping is a side product with possible edge cases - Adds variable names to be part of the API - implementation complexity In my opinion plain skipping parameters is a nice addition to PHP even if named arguments will be introduced. A special character would indeed the best option but as long as there is no good character it's not an option. @Stas: Any news on using default on inheritance ? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
On 20.01.2015 22:46, Nikita Popov wrote: On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz dev@mabe.berlin mailto:dev@mabe.berlin wrote: valid for call_user_func[_array] and callable type-hint but invalid for for direct variable calls: - string MyClass::staticFunc - string self::staticFunc - string static::staticFunc - string parent::func - string parent::staticFunc see http://3v4l.org/1oSO3 Thoughts ? I would prefer deprecating this alternative notation instead of adding more support for it. The [$class, $method] form is the canonical form we support everywhere and which is consistent with the [$obj, $method] callbacks. There's no point supporting another alternative notation, especially if it was effectively unusable for a while now already. I don't think removing this is an option because of a big BC for no reason. Additionally the string alternative have some advantages: - better usable in configurations - return syntax of third argument of is_callable - ... Nikita Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
valid for call_user_func[_array] and callable type-hint but invalid for for direct variable calls: - string MyClass::staticFunc - string self::staticFunc - string static::staticFunc - string parent::func - string parent::staticFunc see http://3v4l.org/1oSO3 Thoughts ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove $this from incompatible context
Hi Stas,
Am 12.02.2015 um 22:31 schrieb Stanislav Malyshev:
Hi!
class A {
// This is an *instance* method, but it doesn't actually use $this.
// This kind of usage is very common in PHP 4 era code, where
// static annotations weren't used
function test() {
echo foo;
}
}
class B {
function test2() {
// This call would be forbidden because it assumes $this of class
B, when
// calling an instance method of class A. However A::test() does
not actually
// use $this!
A::test();
}
}
IMHO, this should work. Maybe issue E_STRICT, but even then I'd think
it's not really necessary, I can't see any purpose E_STRICT serves in
this case - since $this is not used, no potential bug is averted, as the
code works exactly as it was supposed to be working.
Such code will break, not in the first place but later on!
You propose that every instance method not using the variable $this
internally will be magically a static method and can never ever be
changed to use $this without an bc break.
snip
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove $this from incompatible context
Hi Am 13.02.2015 um 08:48 schrieb Stanislav Malyshev: Hi! there should be no bc break as the API doesn't change and the method produces the exact same result as before. Sorry, this makes no sense to me. You claim that if you changed the method code to do different thing it should continue working as if you didn't change it? Why? I just don't get it. It's not a good thing to magically change the method API in base of a method body that's not port of the API. magically change the method API? What are you talking about? You changed the code, not magic. Sorry it wasn't clear. I hope I will now: The static modifier for methods is part of the method signature and method body isn't. (That's way interfaces doesn't describe method bodies but signatures) The static modifier defines a method as static and therefore defines the method is callable using ::. What I mean with magically is that you like to define a method as static without the static modifier in base of the method body but the body isn't part of the signature. Now if you change the method body only without this very special knowledge into something using $this you break all code that calls the method statically. So for me a +1 to throw an E_DEPRECATED error in this case and remove this feature in PHP 8. This will inform existing applications about the wrong call and provide enough time to be fixed. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function
Am 20.03.2015 um 09:03 schrieb Wei Dai: Hi internals, Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Any objections? Why not simply allow the callback to be an array, too? — Wei Dai -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function
I also had a question! Didn't you noticed it? Am 20.03.2015 um 16:49 schrieb Marc Bennewitz: Why not simply allow the callback to be an array, too? Marc Am 21.03.2015 um 09:14 schrieb Xinchen Hui: Hey: On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui larue...@php.net wrote: Hey: On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams a...@phcomp.co.uk wrote: On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote: On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote: Hi internals, Hi internals, The RFC to add a user-land function for an easy-to-use and reliable preg_replace_callback_array() in PHP is up for discussion: https://wiki.php.net/rfc/preg_replace_callback_array This proposes adding one function: `preg_replace_callback_array()` that is the better way to Implement when there are multiple patterns need to replace. I would love to hear your feedback! :) Any objections? I’ve sent this mail for four days, I don’t know if this RFC needs a vote. If you guys have no objections on this, please review the code and merge it, thanks. Nice job, i like the idea. I am not sure about a RFC or not. It somehow looks like a sane replacement for something we killed (with good reasons). Let see what the other think :) I used s/something/code/ge in a perl script that I wrote a few days ago. Very useful. It would have been a lot more work to do it another way. So: +1 to the ability to do this, regardless of what mechanism is eventually chosen. I also +1 for this. if there is no objections raises, I am going to merge it tomorrow.. merged thanks thanks -- 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 -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception hierarchy: open issues
Am 30.03.2015 um 12:58 schrieb Thomas Punt: Hey, Imho TypeException may not be best name for it, as it's also thrown for non-type related error conditions, like mismatched argument count. Would SignatureException be a more apt name for these error conditions? We already have an InvalidArgumentException but this one extends LogicException extends Exception -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
Am 01.03.2015 um 20:04 schrieb Dan Ackroyd:
On 1 March 2015 at 18:35, Marc Bennewitz dev@mabe.berlin wrote:
What are the reasons to not make this class instantiable / extendable ?
That class handles database state / resources that are not exposed
through the userland classes. It's correct in my opinion for it to not
be extendible or instantiable. Obviously it would be awesome if they
were covered by an interface, to allow testign to be easier, but
that's a separate issue.
That's definitely better but it's an behavior not possible to implemented in
user land code as it would be impossible to get such an object.
The same behaviour can seen with the code below.
cheers
Dan
class Foo {
private static $internalConstruction = false;
public function __construct() {
$constructionAllowed = !self::$internalConstruction;
self::$internalConstruction = false;
if ($constructionAllowed == false) {
throw new \Exception(External construction not allowed);
}
}
public static function create() {
self::$internalConstruction = true;
return new self();
}
}
$foo = Foo::create();
var_dump($foo);
$bar = new Foo();
OK you are right but it's ugly code and the not callable constructor
needs to be documented as it's not visible without calling.
The following would be the standard way to go:
final class PDORow {
private function __construct() {
// ...
}
public static function create() {
return new self();
}
}
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
Hi Dan, Am 01.03.2015 um 15:55 schrieb Dan Ackroyd: Hi Internals, This email is to announce the formal opening of discussion for an RFC to clean up the behaviour of the constructors shown by several internal classes. https://wiki.php.net/rfc/internal_constructor_behaviour I really like this RFC as it reduces WTF moments a lot! One note from my perspective: The class PDORow is not instantiable and triggers a fatal errors currently. You propose to change the fatal error into an exception. That's definitely better but it's an behavior not possible to implemented in user land code as it would be impossible to get such an object. To define a class not instantiable in user land would be to define the constructor private/protected. Btw. What are the reasons to not make this class instantiable / extendable ? Thoughts? For reference this was discussed before https://marc.info/?l=php-internalsm=142150339323854w=2 As this RFC targets PHP 7, I plan to open the voting before the cut-off date. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal: deprecate undefined passed arguments
Hi all,
Because the feature freeze for PHP 7 is near I like to know your
thoughts about one more change in passing arguments. Sure this one would
introduce one more deprecated message / BC break but this one s for
reducing BC break in the future!
Currently a caller can pass undefined arguments as much he like. Such
passed arguments are only visible by the callee using
func_get_args/func_num_args but the need for such function definitions
has been gone with argument unpacking feature. The other rare
possibility for ignoring passed arguments by callables from functions
like array_walk has been gone, too, with the introduction of clusures.
By the way we already have internal functions triggering warnings on
unknown arguments. This is also an unneeded inconsistency and more it's
invisible by the user without testing each function for it.
At least simply ignoring passed arguments is a violation as described in
the following examples (http://3v4l.org/U2lnf):
class Calculator {
public function calc($v) {
return $v + 1;
}
}
class MyCalculator extends Calculator {
public function calc($v1, $v2 = 0) {
return parent::calc($v1) + $v2;
}
}
function calcArray(array $values, Calculator $calculator) {
foreach ($values as $v) {
$v = $calculator-calc($v, $v); // Second argument is wrong !!
}
return $values;
}
$ar = [1,2,3];
var_dump(calcArray($ar, new Calculator)); // ignores the second argument
var_dump(calcArray($ar, new MyCalculator)); // UNEXPECTED: the second
argument will be used
Both calculators should be 100% compatible but they aren't as the
function calcArray shows.
So because of the described issues with the existing code base I like to
propose the change to no longer ignore undefined arguments and introduce
E_DEPRECATED messages if a function get's an undefined argument. So the
user get enough time to fix their code before throwing errors in this
case in PHP 8.
As this should be consistent over the engine I would propose this change
for user defined functions and for internal functions as well.
Again, yes this one would introduces one more BC break but first this
would be deprecated before disabled and next it's for reducing BC in the
future.
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
Hi Dimitry, Am 19.02.2015 um 16:13 schrieb Dmitry Stogov: Hi Nikita, I refactored your implementation: https://github.com/php/php-src/pull/1095 I introduced a class hierarchy to minimize effect on existing code. cacth (Exception $e) won't catch new types of exceptions. BaseException (abstarct) +- EngineException +- ParaseException +- Exception +-ErrorException +- all other exceptions I really like this RFC and Exception hierarchy but one very small note: The name of BaseException is a bit to misunderstanding to me as it clashes with the old base exception named Exception, which is by the way very often used as alias (use Exception as BaseExcepton). I know this isn't a technical issue but it reduces readability a code. What are your thoughts about the following names ?: RootException AbstractExcepton snip Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: deprecate undefined passed arguments
Hi Marcio,
Am 23.02.2015 um 21:15 schrieb Marcio Almada:
2015-02-23 16:32 GMT-03:00 Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin:
Hi all,
Because the feature freeze for PHP 7 is near I like to know your
thoughts about one more change in passing arguments. Sure this one
would introduce one more deprecated message / BC break but this
one s for reducing BC break in the future!
Currently a caller can pass undefined arguments as much he like.
Such passed arguments are only visible by the callee using
func_get_args/func_num_args but the need for such function
definitions has been gone with argument unpacking feature. The
other rare possibility for ignoring passed arguments by callables
from functions like array_walk has been gone, too, with the
introduction of clusures.
By the way we already have internal functions triggering warnings
on unknown arguments. This is also an unneeded inconsistency and
more it's invisible by the user without testing each function for it.
At least simply ignoring passed arguments is a violation as
described in the following examples (http://3v4l.org/U2lnf):
class Calculator {
public function calc($v) {
return $v + 1;
}
}
class MyCalculator extends Calculator {
public function calc($v1, $v2 = 0) {
return parent::calc($v1) + $v2;
}
}
function calcArray(array $values, Calculator $calculator) {
foreach ($values as $v) {
$v = $calculator-calc($v, $v); // Second argument is wrong !!
}
return $values;
}
$ar = [1,2,3];
var_dump(calcArray($ar, new Calculator)); // ignores the second
argument
var_dump(calcArray($ar, new MyCalculator)); // UNEXPECTED: the
second argument will be used
Both calculators should be 100% compatible but they aren't as the
function calcArray shows.
So because of the described issues with the existing code base I
like to propose the change to no longer ignore undefined arguments
and introduce E_DEPRECATED messages if a function get's an
undefined argument. So the user get enough time to fix their code
before throwing errors in this case in PHP 8.
As this should be consistent over the engine I would propose this
change for user defined functions and for internal functions as well.
Again, yes this one would introduces one more BC break but first
this would be deprecated before disabled and next it's for
reducing BC in the future.
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Have you checked https://wiki.php.net/rfc/strict_argcount? Only
difference is that I'm proposing a warning instead of E_DEPRECATE, but
it's still a draft and open to discussion. Maybe you would like to
contribute to the RFC before it reaches discussion this week?
Wow, nice to see this - didn't noted it before.
But I have to questions/notes:
1. Why you throw only a warning and not an error (deprecating this
feature first). I don't see the benefit.
2. As I understand it correctly passing unknown arguments will be
allowed if the function uses one of the|func_[get|num]_arg[s]()| functions.
This looks wired to me as the caller should not know the body to know
how a function can be called
and because of the dynamic nature of PHP this check isn't possible in
all cases as you already noted.
Additionally such strict check is for detecting wrong calls but this
detection doesn't work with code like this:
https://github.com/zendframework/zf2/blob/master/library/Zend/Cache/Storage/Adapter/Memcached.php#L213
In my opinion functions using |func_[get|num]_arg[s]() |to implement
variadic arguments are totally outdated and should be refactored using
new semantic. I also think such code isn't used very often and
deprecating it + removing later on (PHP 8) will give more than enough
time to update it as it's simple to find and simple to fix.
Also to previous example given for ZF2 shows that the function
|func_num_args()| have it's rights to exit but i'm unsure about
|func_get_arg[s]()|.
Marc
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Am 30.04.2015 um 14:30 schrieb Julien Pauli: On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebast...@php.net wrote: Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev: I like the idea, however we do have the deadline and the deadline has been passed. So I wonder if we can't keep it for 7.1 That means introducing a change in 7.0, changing it and deprecating part of it in 7.1, and removing said part in 7.2/8.0. Makes no sense to me. Either do it now for 7.0 or don't do it. I tend to agree here. If we introduce BaseException, deprecating it one year later (probably) is a bad idea IMO. We could make an exception (sic !) and add the Throwable interface to PHP7, even after feature freeze, because it is an easy pick and having a clear Exception model for 7.0 is to my opinion very important. This would be very great! If I remember right, on base discussion the BaseException vs. Throwable interface was called an implementation detail that can be changed later on. And on vote it was only some weeks before feature freeze so it would be impossible for the Throwable interface to pass before freeze. Julien.Pauli Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
Hi Nikita, Dmitry,
I think it's a mistake to throw a TypeException on invalid argument
count as in this case it has nothing to do with a type.
Marc
Am 03.04.2015 um 20:48 schrieb Dmitry Stogov:
I don' t see any problems.
Thanks. Dmitry.
On Fri, Apr 3, 2015 at 6:31 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Apr 1, 2015 at 3:31 AM, Dan Ackroyd dan...@basereality.com
wrote:
Hi Dmitry,
Your approach is definitely a better one, and I have no objection to
it whatsoever.
Sorry, I was too busy to look deeply at each class but I can't see any
problems.
Nikita Popov wrote:
does that mean that the same code using strict_types=1 mode will start
throwing TypeException instead of whatever exception type is passed
to replace_error_handling?
That's going to affect everything isn't it - not just this RFC?
However I think that is the correct behaviour. It more closely
resembles the behaviour that will be seen in userland code, and is
more 'semantically' meaningful i.e. it allows people to tell the cases
between the two types of errors apart.
It probably bears more thinking about though.
cheers
Dan
$formatInfoList = [
[en_US, {0,number,integer} monkeys on {1,number,integer} trees
make {2,number} monkeys per tree],
[en_US, '{this was made intentionally incorrect}'], //valid type
but wrong value
[en_US, new StdClass] //wrong type
]
foreach ($formatInfoList as $formatInfo) {
list($locale, $pattern) = formatInfo;
try {
$mf = new MessageFormatter($locale, $pattern);
echo $mf-format(array(4560, 123, 4560/123));
}
catch(IntlException $ie) {
// A strict type-est person would not want this to catch the
case where
// the wrong type has been passed, as it's not an exception
related to Intl
// it's an exception related to the type being wrong.
}
}
PR for throwing TypeException (independently of strict mode) for zpp
failures in constructors is here: https://github.com/php/php-src/pull/1215
Will apply it if nobody sees a problem with it.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fix division by zero to throw exception
Am 04.04.2015 um 00:13 schrieb Andrea Faulds: On 3 Apr 2015, at 23:08, Dmitry Stogov dmi...@zend.com wrote: On Apr 4, 2015 12:34 AM, Nikita Popov nikita@gmail.com wrote: Don't think we need to disable compile-time evaluation for 2) and 3). It'll just end up being a compile error in that case. I think if you have 1 % 0 occurring in your code literally, it's better to have the compile fail rather than getting (or not getting) a runtime exception. This is even easier. Andrea, what do you think? I was wondering if that might cause problems if you have a large codebase and some unfixed errors in a few places. If the code isn’t being run, only compiled, then it’d be unnecessary pain. However, the chances of a codebase having numerous undetected divisions by zero, that are obvious at compile-time, aren’t very high. So, failing at compile-time is fine. And, to save another email, I agree with the four items in your summary. Exceptions for negative shift, modulo/intdiv by zero, normal division by zero is +/-INF. :) If the normal division by zero produces +/- INF it's a valid calculation and shouldn't trigger a warning else it should end up in an exception, too. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate setlocale?
Am 01.04.2015 um 18:15 schrieb Dan Ackroyd: Hi, I'd like to get people's feedback for the idea of making setlocale be either deprecated and to be removed eventually or just increasing the warning level against people using it. What if the system is configured with a different locale? OK we could change the locale on startup to C but this could break embedded behaviour and doesn't solve the issue at all. There are some cases where we don't have a good alternative like fgetcsv / fputcsv. The short version of why we should do this is that setlocale breaks things. It is a process wide operation, that is not thread safe on most platforms. Although people use it to alter the way strings are output, it also breaks libraries that are assuming that they are running in a C locale. From my perspective Functionality not related to locale should not be effected by this global - The following bug reports are valid bugs and should be resolved https://bugs.php.net/bug.php?id=59571 - breaks Imagick https://bugs.php.net/bug.php?id=69348 - breaks MySQL - If it's part of the wrapped library it's a bug of this library and should be fixed there Basic PHP functions should be possible to be TS and therefore should ignoring such global configuration else it's impossible to have a TS version of PHP - if there is no alternative functionality we should add one - Non-TS functions should be moved into an extension and don't allow to enable on TS build - Non-TS functions not movable to an extension should be rethink like: - removing the locale based conversion on simple float to string casts - make strtoupper/strtolower etc. to work with ascii only Is't there a very similar issue with fs operations and umask? - Is it possible to have fs operations not related on this non-TS global configuration? https://bugs.php.net/bug.php?id=59571 - breaks Imagick - It's a real bug and should be fixed (not locale based functionality) https://bugs.php.net/bug.php?id=54538 - breaks NumberFormatter - It's a real bug and should be fixed (based on a different safe locale) https://bugs.php.net/bug.php?id=66108 - breaks constants - see comment above about strtoupper https://bugs.php.net/bug.php?id=67127 - breaks DateTime - It's a bug and should be fixed (not locale based functionality) https://bugs.php.net/bug.php?id=69348 - breaks MySQL - It's a bug and should be fixed (non locale based functionality) - Couldn't this one be a security issue And there are quite a few other bug reports where setlocale is doing exactly what it is meant to do, but the unexpected side-effects are catching people out. We have libraries that ship with PHP for formatting dates, numbers etc that actually work, and don't break other libraries. So two questions: i) Are there any reasons why we couldn't or shouldn't plan for removing setlocale at some point in the future? i.e. does it do something that isn't supported by other libraries in PHP? ii) If it's not possible (or desirable) to remove it, how could we increase the warning level against using it? cheers Dan Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Overwrite return type-hint into a more specific one
Hi internals, On experimenting with return type-hints I noted an inconsistency on overwriting an existing hint to a more specific one. On adding a non existing return type-hint on overwrite it's fine but it's logically the same (this previously was an E_STRICT). http://3v4l.org/YdB8s - works fine (E_STRICT lower then php7@20150401) http://3v4l.org/UDk0n - Fatal error: Declaration of Bar::setTest() must be compatible with Foo::setTest($test): Foo http://3v4l.org/AuOsr - HHVM works fine Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate setlocale?
Am 01.04.2015 um 20:58 schrieb Stanislav Malyshev: Hi! https://bugs.php.net/bug.php?id=67127 - breaks DateTime This looks like misunderstanding how float-to-string works. If you asked it to put commas as decimal separator, don't be surprised it puts commas as decimal separator. This should be true for number formatting but it's not true for date format. - I'm a german with comma (,) as decimal separator and I have never seen such a comma in microtime separation - There is no way to define this behavior in a date format Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate setlocale?
Hi Am 01.04.2015 um 21:02 schrieb Stanislav Malyshev: Hi! - make strtoupper/strtolower etc. to work with ascii only This would be a bad idea, however much better idea is to make *system* case folding (i.e. methods, classes, etc.) use ascii-only. Which we already mostly do (see zend_operators.c it explains what's going on). Of course, there can be instances of using the wrong function. In a dynamic language like PHP it's a very normal and basic case handling language features dynamically including the one described in the bug report (Find an upper case constant for the given input). What I mean is that we should have basic functions addressing this. So for example we need a basic function to upper/lower case only ascii characters. Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Overwrite return type-hint into a more specific one
Hi Anthony,
Am 01.04.2015 um 21:25 schrieb Anthony Ferrara:
Marc,
On Wed, Apr 1, 2015 at 2:46 PM, Marc Bennewitz dev@mabe.berlin wrote:
Hi internals,
On experimenting with return type-hints I noted an inconsistency on
overwriting an existing hint to a more specific one. On adding a non
existing return type-hint on overwrite it's fine but it's logically the same
(this previously was an E_STRICT).
http://3v4l.org/YdB8s - works fine (E_STRICT lower then php7@20150401)
http://3v4l.org/UDk0n - Fatal error: Declaration of Bar::setTest() must be
compatible with Foo::setTest($test): Foo
http://3v4l.org/AuOsr - HHVM works fine
That's the concept of Variance:
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
Specifically, that return types can be covariant (subtypes can
narrow return types) and parameters can be contravariant (subtypes
can widen paramters). So this is valid:
class A extends B {}
class C {
public function foo(A $b): B {}
}
class D extends C {
public function foo(B $b): A {}
}
In that everything that C::foo accepts, D::foo accepts, but D::foo can
accept more.
And D produces more strictly (in that anything that can work with a
product of C::foo can work with what D::foo produces).
We looked into doing this for return types (and all other
declarations). However, we ran into some non-trivial problems around
compilation.
Currently, types are never loaded from a declaration. They are only
loaded when instantiated. Therefore, it's completely possible to have
a declared class with undeclared type declarations. If the type
declaration remains undeclared when you call the method, it's by
definition a failed type (since `$obj instanceof UndefinedClass` is
always false).
Currently in the case of class A extends B {} and B wasn't defined it
will be already loaded by autoloader.
In the case for $obj instanceof UndefinedClass it can't be possible as
$obj was already instantiates and can therefor never be an instance of
an currently undefined class. - no autloading needed.
If we want to check variance, we need to know about the type at
compile time. This brings up an issue that basically makes it
impossible to separate code into multiple files without an autoloader.
For example:
?php // a.php
class A {
public function foo(B $bar) {}
}
?php // b.php
class B {
public function bar(A $foo) {}
}
You couldn't have that be possible without an autoloader, since
there's a circular dependency. Sure, we could (and should) special
case the doesn't inherit situation, but it's pretty trivial to make
a new example which requires an autoloader.
So that leaves us with a weird situation: to support the feature (in
general), you'd have to use an autoloader or put everything into a
single file. That may be OK, but it's also added complexity.
To the best of my knowledge, Levi removed variance from the proposal
to keep it simple (just like nullables weren't in the proposal):
https://wiki.php.net/rfc/return_types#variance_and_signature_validation
If you'd like to create a proposal for 7.1 to add variance support to
type declarations, I think that would be awesome. It's not terribly
difficult, but there are some gotchas (especially around opcache
support) and non-trivial tradeoffs involved.
Thank you for the really helpful explanation!
Now I understand the reasons but I don't have enough experience in C or
the engine to make that possible.
Would it be possible to support it in the first place only if the return
type hints are already known by the engine?
Anthony
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Migrating PHP classes to built in namespace
On 06/04/2015 10:01 AM, Yasuo Ohgaki wrote:
Hi all,
On Thu, Jun 4, 2015 at 12:07 AM, Sara Golemon poll...@php.net wrote:
On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate
codekest...@googlemail.com wrote:
Has there been any discussion or consideration towards migrating or at
least aliasing all built in classes to a Php vendor namespace?
Not any that's led to a consensus.
Personally, I like the idea of moving EVERYTHING to PHP\ at once and
building in an automatic fallback, so an app could do:
?php
$dt = new DateTime(...); // uses builtin DataTime via fallback to PHP
namespace
Or:
?php
class DateTime { ... }
$mydt = new DateTime(...); // Uses user supplied DateTime
$pdt = new PHP\DateTime(...); // Uses builtin DateTime
It's acceptable option, but I prefer explicit declaration for clean root
namespace.
Possibly paired with the ability to import a NS to root:
?php
use PHP as \;
$pdt = new DateTime(...); // Uses builtin DateTime from root namespace
+1 for as \
It achieves both clean namespace and compatibility at the same time.
It opens door for easier API version up also. Automatic fallback disturbs
this.
This one is not compatible with current code as you have to alias the
PHP namespace to the root one before using full classes like \DateTime.
PS: I like a lower case php much more than upper case PHP ;)
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call overhead
On 06/04/2015 06:35 AM, Yasuo Ohgaki wrote: Hi Brian, On Thu, Jun 4, 2015 at 7:33 AM, Brian Moon br...@moonspot.net wrote: This is a better representation of what you are trying to show. It removes all the magic call back stuff that could be adding to the slowness you are seeing. In addition, it does not create a new object on every call for the object method. Creating a new object is going to explicitly slow things down. But, it's not related to the call time. http://3v4l.org/biM9G This version adds up precision errors because microtime() precision is not high enough for the purpose. Since the error is random, it does not affect proportion much but total execution time. Following damn code does better job for these kinds of benchmarks. http://3v4l.org/eJK07 See the total amount of execution time recorded. If we really need pure execution time, then it should record for loop execution time with empty body. - incl. displaying the time for the loop: http://3v4l.org/1vZJI Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 09:31 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
I would really like to see directly calling a string of Class::method
be fixed for 7.0.
It's currently resulting in a fatal error and is inconsistent with
call_user_func[_array], is_callable and the callable type-hint.
There is also a PR open since April 2014 :
https://github.com/php/php-src/pull/659
Apparently, your PR has been overlooked, but it seems this is already
implemented as result of merging PR #1264[1]; see
http://3v4l.org/W8hQA. Can you please verify, and close your PR #659
as appropriate.
[1] https://github.com/php/php-src/pull/1264
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined function
Foo::()
This behavior is inconsistent!
Thanks
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 09:39 PM, Marc Bennewitz wrote:
On 06/25/2015 09:31 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
I would really like to see directly calling a string of Class::method
be fixed for 7.0.
It's currently resulting in a fatal error and is inconsistent with
call_user_func[_array], is_callable and the callable type-hint.
There is also a PR open since April 2014 :
https://github.com/php/php-src/pull/659
Apparently, your PR has been overlooked, but it seems this is already
implemented as result of merging PR #1264[1]; see
http://3v4l.org/W8hQA. Can you please verify, and close your PR #659
as appropriate.
[1] https://github.com/php/php-src/pull/1264
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined
function Foo::()
This behavior is inconsistent!
Thanks
Marc
It's also inconsistent with $callable = ['Foo', ''];
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 05:03 PM, Kalle Sommer Nielsen wrote: Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. I would really like to see directly calling a string of Class::method be fixed for 7.0. It's currently resulting in a fatal error and is inconsistent with call_user_func[_array], is_callable and the callable type-hint. There is also a PR open since April 2014 : https://github.com/php/php-src/pull/659 Thanks, Kalle, Anatol Ferenc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/28/2015 09:22 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
On 06/25/2015 09:48 PM, Aaron Piotrowski wrote:
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined
function Foo::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Is this edge case addressed now?
My PR has been closed now where this edge case was addressed, too.
That is supposed to be addressed by
http://git.php.net/?p=php-src.git;a=commit;h=ba67fc221890aaa395912aefebb96155afe671c1.
Can you please confirm with a recent master? (The Windows snapshots
currently in build progress are likely to have this commit included, too.)
It's fixed now - Thanks! :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 09:48 PM, Aaron Piotrowski wrote:
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined
function Foo::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Is this edge case addressed now?
My PR has been closed now where this edge case was addressed, too.
Thanks,
Aaron Piotrowski
Thanks
Marc
Re: [PHP-DEV] [RFC] Throwable Interface
On 05/23/2015 10:12 PM, Aaron Piotrowski wrote: Hello, I’ve created an RFC for modifying the exception hierarchy for PHP 7, adding Throwable interface and renaming the exceptions thrown from fatal errors. The RFC is now ready for discussion. RFC: https://wiki.php.net/rfc/throwable-interface https://wiki.php.net/rfc/throwable-interface Pull Request: https://github.com/php/php-src/pull/1284 https://github.com/php/php-src/pull/1284 I like this RFC! It's much more intuitive as the current BaseException approve. Some small notes: Backwards Compatibility |Throwable|, |Error|, |TypeError|, and |ParseError| will no longer be available in the global namespace. Where are the new classes and the interface located if it's not in the global namespace or do I muss something? If I remember right the TypeException/TypeError will be thrown in some cases of internal functions with strict argument count. In my opinion a missing argument or to much arguments has nothing to do with the type and should have it's own Exception/Error class. Aaron Piotrowski Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On 05/24/2015 10:11 PM, Aaron Piotrowski wrote: On May 24, 2015, at 2:08 PM, Marc Bennewitz dev@mabe.berlin wrote: Where are the new classes and the interface located if it's not in the global namespace or do I muss something? Sorry if what I wrote wasn’t clear. Throwable, Error, TypeError, and ParseError will be built-in interfaces/classes in the root namespaces. So users will not be able to make classes with those exact names, but classes with those names in a non-global namespace (e.g., \Vendor\Package\TypeError) will still be possible. I’ve updated the RFC to make this clearer. Thanks If I remember right the TypeException/TypeError will be thrown in some cases of internal functions with strict argument count. In my opinion a missing argument or to much arguments has nothing to do with the type and should have it's own Exception/Error class. I believe this actually generates a warning, it does not throw an exception. However, this does remind me of another point: It is possible that more classes extending Error could be created in the future for different error reasons. Anything that throws an Error could later be changed to throw an object extending Error without a BC break. This is a separate issue though and could be discussed in a future RFC. Ok than I remember wrong. Aaron Piotrowski Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On 05/24/2015 11:32 PM, Yasuo Ohgaki wrote: Hi Aaron, On Sun, May 24, 2015 at 5:12 AM, Aaron Piotrowski aa...@icicle.io wrote: I’ve created an RFC for modifying the exception hierarchy for PHP 7, adding Throwable interface and renaming the exceptions thrown from fatal errors. The RFC is now ready for discussion. RFC: https://wiki.php.net/rfc/throwable-interface https://wiki.php.net/rfc/throwable-interface Pull Request: https://github.com/php/php-src/pull/1284 https://github.com/php/php-src/pull/1284 Does this include internal function type errors? e.g. $ php -r 'var_dump(mt_srand(999));' PHP Warning: mt_srand() expects parameter 1 to be integer, string given in Command line code on line 1 NULL If not, please make these exceptions rather than E_WARNING. We need consistency here. This would be great for strict_types mode as there it results in a fatal error. http://3v4l.org/vHl8K Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ::class wrong case
Hi, I have noted that detecting a class name using ::class it will return the called case instead of the original case. see http://3v4l.org/97K36 That's annoying as I like to check the right class case on autoload to detect mistakes. Sure, class names in PHP are case-insensitive but filesystems aren't and most autoloader using the FS to find the right file. To catch such kind of mistakes I would like to implement a fast check in my autoloader to get noted on development instead on production. It's currently only possible with ReflectionClass but this will be much slower as with ::class. Are there any reasons to get the called case of the class instead or the original one? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Question] Variadic method signature compatibility between 5.6 and 7.0
Hi Rowan,
On 11/02/2015 05:41 PM, Rowan Collins wrote:
Alexander Lisachenko wrote on 02/11/2015 11:12:
First definition declares exactly one single parameter, which can be
absent during the method call, so I can even write
public static function test() {}
Second definition defines zero or more arguments, so it can be also
described by the same signature:
public static function test() {}
OK, I got a bit confused with the different optional parameters, and
neither your explanation nor Andrea's quite did it for me.
But, I think you're right that this should be compatible, if the rule
is "any legal call on the parent should also be legal on the child".
Currently, all versions of PHP enforce the following:
- if parent accepts no parameters, child must accept zero, but could
accept one or more optional parameters
- if parent accepts zero or one (an optional parameter), child must
accept zero, must accept one, but could accept more (so, two optional
parameters is fine; no parameters at all is incompatible)
Thus this is acceptable:
class Foo {
public function test() {}
}
class Bar extends Foo {
public function test($foo = null) {}
}
But these are all not:
class Foo2 {
public function test($foo = null) {}
}
class Bar2 extends Foo2 {
// Doesn't accept one parameter
public function test() {}
}
class Baz2 extends Foo2 {
// Doesn't accept zero parameters
public function test($foo) {}
}
class Foo3 {
public function test() {}
}
class Bar3 extends Foo3 {
// Doesn't accept zero parameters
public function test($foo) {}
}
Variadic signatures count as "zero or more" when the parent accepts
only zero:
class Foo4 {
public function test() {}
}
class Bar4 extends Foo4 {
public function test(...$foo) {}
}
But where the parent accepts "zero or one", the following ought to be
compatible because calls with no parameters, and calls with one
parameter, would both be valid:
class Foo {
public function test($foo = null) {}
}
class Bar extends Foo {
public function test(...$foo) {}
}
In short, I agree with you that this warning is incorrect, but will
leave this here in case anybody else is equally confused (and becomes
any less so by reading this...)
In my opinion the warning is valid as the one method defines one
optional argument and the overwritten method would accept no or more
arguments where the no arguments is wrong:
https://3v4l.org/6eMiu
class Foo {
public function test($foo = null) {}
}
class Bar extends Foo {
public function test() {}
}
The first defined argument gets more interesting if it defines a
type-hint what is not possible to define as variadic:
https://3v4l.org/HQdvI
class Foo {
public function test(Foo $foo = null) {}
}
class Bar extends Foo {
public function test(...$bar) {}
}
Additionally this issue can simply be addressed by:
https://3v4l.org/74r3K
class Foo {
public function test(Foo $foo = null) {}
}
class Bar extends Foo {
public function test(Foo $foo = null, ...$bar) {}
}
Regards,
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 10/15/2015 01:19 AM, Larry Garfield wrote:
On 10/14/2015 06:00 PM, Andrea Faulds wrote: >> Both you and Stas have said this, but it's only true if we solely
>> consider C-like languages. Other languages do different things. In
>> the PHP manual, Hack, TypeScript, ActionScript, and most likely
other >> languages (these are just off the top of my head), `void`
functions >> do still have an implicit result. >> >> All of these
languages would have had the choice to do what you're >> suggesting and
use `null`, or its equivalent (`undefined` for >> TypeScript and
ActionScript). They didn't. Why? If I had to guess, >> there's at least
three reasons. For one, void is the word languages >> usually use for
this. For another, `void` and `null` they mean >> different things.
`void` signifies a function isn't returning >> anything. `null`
signifies a function that *returns null*, regardless >> of where that
null came from. `function foo(): null { return >>
some_probably_null_returning_function(); }` should surely be legal >>
with a `null` type hint, yet it's nonsensical code. Finally, making a >>
function truly "return nothing", i.e. disallowing its use as an >>
expression/rvalue, breaks some use cases, like passing along the >>
result of a callback. >> >> PHP would neither be the first nor the last
to be using `void` in >> this way. >> >>> If the union types RFC[2]
passes it >>> makes sense to allow `Foo | null` which allows something
of type `Foo` >>> or `null`. To me it makes sense that if you then
remove `Foo` you are >>> left with `null`, not `void`. My personal
recommendation because of >>> this would be to use `null` for the return
type and instead of `void`. >> >> `null` would be a weird type, because
it doesn't make sense as a >> parameter type, and as a return type, you
don't really want to >> enforce returning null, you want to enforce not
returning at all (see >> the example above). It feels like a poor man's
substitute to me. >> >> Thanks. > > The tricky part here is that saying
a function does not return is not > something PHP currently does: > >
https://3v4l.org/HtAuC > > No return implicitly returns NULL, which you
can assign to a variable > if, for some strange reason, you were so
inclined. So this would be > more than "just" a syntactic documentation
feature. > > Which I believe gives the following options: > > 1) Change
the language behavior such that > > function foo() : void { ...} > $a =
foo(); > > Is a syntax error (because there really was nothing returned
to > assign), rather than resulting in $a having a value of NULL. > > 2)
Use null as a "type" (which I agree feels weird just saying it), > such
that: > > function foo() : null { ...} > $a = foo(); > > and > >
function foo() { ...} > $a = foo(); > > are identical. The former would
impact the contents of the function > (eg, a non-empty return would be a
parse error), but the external > result is the same ($a == NULL). > > 3)
Use the "void" keyword, but give it the same effect as option 2. > > The
RFC currently seems to propose option 3 (based on the "Use of void >
functions in expressions" section). I don't have a strong feeling at >
this point about which option I'd prefer. >
Option 4)
// implicit return void
function foo () { return; }
// explicit return void
function foo () : void { return; };
// syntax error if returning something on explicit return void
function foo () : void { return null; };
// syntax error on using return value of explicit return void
function foo () : void { return; };
$bar = foo();
// return NULL on implicit return void (this could also give a
warning/notice/deprecated error)
function foo () { return; };
$bar = foo(); // NULL
// mixing return void with any other return values could also result in
a warning/notice/deprecated error
function foo () { if ($bar) return; return $bar; };
--Larry Garfield >
I really like this as in my opinion if a function doesn't return
something it should be part of the function signature and it really
helps to avoid mistakes on writing code.
Marc
Re: [PHP-DEV] Immutable modifier
FYI there was a very small discussion about it ~ 1 year ago
https://www.mail-archive.com/internals@lists.php.net/msg71521.html
On 11/16/2015 10:15 AM, Chris Riley wrote:
Hi,
There has been a lot of interest recently (eg psr-7) in immutable data. I'm
considering putting an RFC together to add language support for immutables:
immutable class Foo {
public $bar;
public function __construct($bar) {
$this->bar = $bar;
}
}
Immutable on a class declaration makes all (maybe only public?) properties
of the class immutable after construct; assigning to a property would
result in a Fatal error.
class Foo {
public $bar;
immutable public $baz;
}
Immutable on a property makes the property immutable once it takes on a
none null value. Attempts to modify the property after this results in a
fatal error.
Any thoughts?
~C
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiers in PHP 7.1+
On 09/07/2015 08:43 AM, Sean DuBois wrote: On Sun, Sep 06, 2015 at 06:47:56PM +0100, Andrea Faulds wrote: Hi Sean, Sean DuBois wrote: I am starting this discussion to get peoples opinion on the overall feature, and find someone who would be interested in watching over my progress and making sure I do the right things to hopefully get this merged. The PHP bug tracker contains a few simple entries for a adding visibility modifiers to class constants. https://bugs.php.net/bug.php?id=27022 I would be the one implementing this, and have a basic working version already (that takes shortcuts like reusing property_info) but it works! https://github.com/Sean-Der/php-src/compare/master...bug-69980-class-constants#diff-6231c13c8582758f41a5e2a015e3b5c5R1 There are cases where runtime/compile time checks pass/fail incorrectly, but working on that now. This change would involve breaking the API, but wouldn't involved any language breaking changes. All current const declarations would just default to public and keep the same behavior. Funny you should propose this now, I was wanting this feature just the other day. This would be a useful addition, and clean up a strange inconsistency: why can methods and properties have visibility modifiers, but not constants? I'd love to see this in PHP. Are you going to write an RFC? Thanks! -- Andrea Faulds http://ajf.me/ Just one of those things that you you wish you had, but then end up solving with other things (static properties) so we will see how long it takes me to blunder through it :) Reeze Xia started an RFC, but didn't have time to finish it. We talked over GitHub and I will be taking it over fully. https://wiki.php.net/rfc/class_const_visibility I am just waiting on RFC Karma, after I get that I will start filling it in! I really like this feature but please make sure it doesn't break BC on usage of Reflection::getConstant(s). For example I'm using this for an implementation of constant based enumerations: (https://github.com/marc-mabe/php-enum/blob/master/src/Enum.php#L277) Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug or expected behavior?
Hi, today I was running into an issue with a function lookup over namespace. https://3v4l.org/qF7cK fails https://3v4l.org/evVic works For me it looks like the function lookup for "is_null" in this case gets cached on first use and on second call no check will be done if this function exists in the current namespace before looking in the root namespace. Because PHP is a dynamic language this behavior looks wrong (unexpected) to me and also HHVM does handle it as I would expect it. Thanks, Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug or expected behavior?
On 05/31/2016 09:59 PM, Nikita Popov wrote: On Tue, May 31, 2016 at 9:54 PM, Marc Bennewitz <dev@mabe.berlin <mailto:dev@mabe.berlin>> wrote: Hi, today I was running into an issue with a function lookup over namespace. https://3v4l.org/qF7cK fails https://3v4l.org/evVic works For me it looks like the function lookup for "is_null" in this case gets cached on first use and on second call no check will be done if this function exists in the current namespace before looking in the root namespace. Because PHP is a dynamic language this behavior looks wrong (unexpected) to me and also HHVM does handle it as I would expect it. Thanks, Marc This is a known issue: https://bugs.php.net/bug.php?id=64346 Much thanks Nikita for the link. Didn't found it myself. But this bug ticket doesn't look nice - No comments since 2¹/² years. Is a suggestion from someone without enough knowledge of the engine / opcache. Wouldn't it be better to move this performance feature into opcache and make it configurable over "opcache.optimization_level <http://php.net/manual/en/opcache.configuration.php#ini.opcache.optimization-level>"? Regards, Nikita Thanks, Marc
