Re: [PHP-DEV] DateTimeInterface is not a usable interface?
On Tue, 21 Jul 2015 15:01:06 +0400, Marco Pivetta ocram...@gmail.com wrote: Hello, I was looking at DateTimeInterface in order to provide my own implementation of it, when I hit this: http://3v4l.org/8GvgO Fatal error: DateTimeInterface can't be implemented by user classes in Is there any actual reason for this kind of limitation? Can it be removed before going stable? I also wasn't able to find any RFC information around it on https://wiki.php.net/rfc#php_55 - is there any previous discussion around this, or did it just sneak its way in? Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ Hey Marco, The discussion was here https://github.com/php/php-src/pull/512 tl;dr core functions that accept DateTime and DateTimeImmutable (DateTimeInterface basically) operate directly on timelib structures hence they will break if you pass them a user-defined class. There's a workaround though - it's to always call user-defined class's method directly from built-in functions, so if you would call (new DateTime())-diff(new UserDefinedDateTime()) it would call UserDefinedDateTime#diff in the end which would need to implement the logic. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On Wed, 25 Feb 2015 16:55:57 +0400, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 25, 2015 at 2:42 PM, Niktia Nefedov inefe...@gmail.com
wrote:
On Wed, 25 Feb 2015 16:30:32 +0400, Dmitry Stogov dmi...@zend.com
wrote:
anyone may tell, what this will print without running :)
main.php
?php
declare(strict_types=1)
include a.php;
include b.php;
var_dump(foo(5));
?
a.php
=
?php
declare(strict_types=0)
function foo(string $a): string {
bar($a);
return $a;
}
?
b.php
=
?php
declare(strict_types=1)
function bar(int $a) {
var_dump($a);
}
?
Thank. Dmitry.
Hi Dmitry,
This will error out because $a in the scope of `foo` will be coerced to
int type when passed to bar by reference.
I think it'll work without errors and produce some explainable but weird
output. I didn't run it myself yet.
Yep, you're right. But it's not a problem of mixed-mode, it's more of a
problem of introducing coercive type hints at all, honestly... I wonder
what Zeev plans to do with __toString coercion in his RFC, because that is
even more severe problem when your object unnoticedly becomes a string.
Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On Wed, 25 Feb 2015 16:30:32 +0400, Dmitry Stogov dmi...@zend.com wrote:
anyone may tell, what this will print without running :)
main.php
?php
declare(strict_types=1)
include a.php;
include b.php;
var_dump(foo(5));
?
a.php
=
?php
declare(strict_types=0)
function foo(string $a): string {
bar($a);
return $a;
}
?
b.php
=
?php
declare(strict_types=1)
function bar(int $a) {
var_dump($a);
}
?
Thank. Dmitry.
Hi Dmitry,
This will error out because $a in the scope of `foo` will be coerced to
int type when passed to bar by reference.
References are a problem for weak-only types as well (even more so I would
say, because in a lot of cases they would continue working truncated or
changed).
Happily there are not lots of post-php5 code that uses references here and
there, but that would be good to add the point about them to both RFCs
(and in documentation in future) just so that users would be aware of that.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
On Wed, 25 Feb 2015 15:42:11 +0400, Niktia Nefedov inefe...@gmail.com
wrote:
On Wed, 25 Feb 2015 16:30:32 +0400, Dmitry Stogov dmi...@zend.com
wrote:
anyone may tell, what this will print without running :)
main.php
?php
declare(strict_types=1)
include a.php;
include b.php;
var_dump(foo(5));
?
a.php
=
?php
declare(strict_types=0)
function foo(string $a): string {
bar($a);
return $a;
}
?
b.php
=
?php
declare(strict_types=1)
function bar(int $a) {
var_dump($a);
}
?
Thank. Dmitry.
Hi Dmitry,
This will error out because $a in the scope of `foo` will be coerced to
int type when passed to bar by reference.
References are a problem for weak-only types as well (even more so I
would say, because in a lot of cases they would continue working
truncated or changed).
Happily there are not lots of post-php5 code that uses references here
and there, but that would be good to add the point about them to both
RFCs (and in documentation in future) just so that users would be aware
of that.
Ah sorry I was too quick on judging, Florian is right, when foo returns
its value it will be coerced back to string because of strict=0 in this
case...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coercive Scalar Type Hints RFC
On Wed, 25 Feb 2015 17:54:21 +0400, Dmitry Stogov dmi...@zend.com wrote:
The object on the call-site should remain to be an object (if it's not
passed by reference), however the called function will receive a string.
It works in PHP-5 and PHP-7. Nothing should be changed.
$ sapi/cli/php -r 'class X {function __toString(){return abc;}} $x=new
X; var_dump(strlen($x)); var_dump($x);'
int(3)
object(X)#1 (0) {
}
However, declare(strict_types=1) will break this. see
https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-ef5bf53d1412b50f85d125ca4fe84741R1182
Thanks. Dmitry.
Dmitry, I was talking about passing an object to a function, expecting a
reference of a string:
'class X { function __toString() { return spl_object_hash($this); } } $x =
new X; function foo(string $x){} foo($x); var_dump($x);'
Now what would this produce in Coercive STH is still an open question I
guess as there is no implementation yet.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Allow to use argument unpacking at any place in arguments list
Hey folks, Currently argument unpacking can only be used once in a call and only after all positional arguments were passed. E.g. func(1, 2, 3, ...[4, 5]) is allowed, but func(...[1, 2, 3], 4, ...[5]) is not. This makes it impossible to use this feature with some of the ext/std functions (array_udiff, array_interect_ukey, etc.) and just feels a bit incomplete... I would like to propose to allow usage of argument unpacking at any place in arguments you are passing. The patch is pretty simple, you look at it here: https://github.com/nikita2206/php-src/compare/master...unpack-mid-argument-list I still haven't tested performance on the real life apps, but all the synthetic benchmarks (incl. deep recursion in order to let call stack go over the cpu cache) show that there's no difference between this patch and master. Callgrind shows that there is a small increase in the number of instructions ran, which is expected but seems as to be negligible. (It's about 0.5% increase for recursion benchmark). I'm not sure if this change requires an RFC because this is a pretty small, advancement of already existing feature that doesn't contain any BC breaks. So I would be happy if this could go forward without it, but if people disagree here I will make an RFC, that's not a problem (although I would need some karma...) -- 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
On Thu, 15 Jan 2015 14:30:48 +0300, Arvids Godjuks arvids.godj...@gmail.com wrote: Hello Andrea! Consider what a mess was register_globals and problems it had, but at least it was a global setting. Declare will work on per file basis, and it will end up even more of a mess. I think PHP development community learned that lesson and that's why you get pushback, and not only from internals, but also from the userland. Me including. What does it have with register_globals in common? Why would it be a mess? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Remove deprecated functionality in PHP 7
On Sun, 21 Dec 2014 06:49:49 +0300, Xinchen Hui larue...@php.net wrote: Hey: On Sun, Dec 21, 2014 at 11:43 AM, Pierre Joye pierre@gmail.com wrote: On Dec 21, 2014 10:23 AM, Xinchen Hui larue...@php.net wrote: Hey: I am strongly against to remove ext/mysql that means, all wordpress users/maintainers, will not able to upgrade to PHP7 without pain. https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/ Basically wp and mysql are wrong arguments. we have upgrade issues, they also have that.. I know lots of sites are based on old version wordpress, and they did lot's of custom developing on it.. they will not able to upgrade to any new wordpress.. Also last time we discussed that there were a couple of oppositions to remove deprecated features in 7. yes.. My take is that we should not have a mass vote but options for each feature. Also if we do not remove deprecated features we may as a well remove the deprecation as it makes no sense to keep it if we never actually remove the affected features. I agree.. for ext/mysql, I think it's okey to remove the deprecated warning.. thanks Cheers, Pierre Hey Xinchen, Couldn't we just write a compatibility layer, like Anthony did for password_hash? (but in the opposite direction, for people who are stuck with ext/mysql and want to upgrade to 7) There'll be one problem with mysqli being an object and not a resource, but I'm sure would be able to solve it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
