Hi,
Le 29/01/2016 08:09, Martin Keckeis a écrit :
Hello,
2016-01-28 21:20 GMT+01:00 François Laupretre :
Hi,
Can you please give your thoughts about a PR I just created :
https://github.com/php/php-src/pull/1741
Loading extensions by name (instead of file name) provides a portable way
of s
On 29/01/16 08:32, François Laupretre wrote:
>> I think 100% portability will not be achieved very soon
>
> You're right, incompatibilities will remain everywhere absolute paths
> are provided but, in many cases, the only differences are the
> 'extension=' lines.
>
> Anyway, the main objective of
Dan Ackroyd wrote on 28/01/2016 22:35:
## Refactoring if non-objects are no longer allowed.
Current code:
echo get_class($result);
Would need to be changed to:
if ($result === null) {
echo get_class();
}
else {
echo get_class($result);
}
You appear to be suggesting that "get_class()" sh
Hi,
> -Original Message-
> From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo
> Ohgaki
> Sent: Wednesday, January 27, 2016 11:05 AM
> To: Anatol Belski
> Cc: Stanislav Malyshev ; Remi Collet
> ; internals@lists.php.net; Yasuo Ohgaki
>
> Subject: Re: [PHP-DEV] PHP 7.0.3
On 28 January 2016 at 23:22, Lorenzo Fontana wrote:
>
> Yes is what I would like to do, start saying people that they should change
> that by triggering a deprecation notice so they can refactor their code.
I don't think we need a deprecation notice. The behaviour when the
function is passed a nu
On 29 January 2016 at 10:46, Rowan Collins wrote:
>
> You appear to be suggesting that "get_class()" should behave differently
> than "get_class(null)".
> I don't know if internal parameter handling (ZPP) works like userland
> parameters
Regardless of how internals works, it's a thing in userland
Results for project PHP master, build date 2016-01-29 06:30:23+02:00
commit: 1b36037
previous commit:8bc8994
revision date: 2016-01-28 18:07:45+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Dan Ackroyd wrote on 29/01/2016 13:56:
On 29 January 2016 at 10:46, Rowan Collins wrote:
You appear to be suggesting that "get_class()" should behave differently
than "get_class(null)".
I don't know if internal parameter handling (ZPP) works like userland
parameters
Regardless of how internals
On 16 January 2016 at 00:28, François Laupretre wrote:
> Le 15/01/2016 19:53, Stanislav Malyshev a écrit :
> Not just a standard text, a new specific 'Require RFC' status too, so that
> they can be easily retrieved.
My initial reaction was to not like that ideabut it's grown on me.
It's a go
Hi!
> It's a good solution to the backlog of issues that have been open for
> years. It also makes it easier to handle new issues as they come up as
> it is more appropriate to put new issues to that state than either
> 'closed' or 'wont fix'.
>
> Who is able to a new 'Requires RFC' state to the
10 matches
Mail list logo
