> On Jul 8, 2021, at 1:26 PM, Rowan Tommins wrote:
>
> for the record, here is what I think:
>
> * Removal of a deprecated feature can be at any point in the future, even the
> indefinite future, just not "never".
> * Very short deprecation periods can be harmful, because they don't give
>
Hi Nikita,
I performed a few other benchmarks in order to provide a little bit more
insights into the performance aspect of the RFC. My latest measurement is
using the same setup as the previous
one, although I made a few smaller changes in the process (e.g. changing
the order of the tests). So
Hi!
Apparently, there has been no resolution for this issue so far. While I
don't really care about the open_basdedir directive per se, I fully
agree that we should not advertize it as security feature, and to
clearly state this in the PHP manual, as well as in our security policy.
Correct.
On 08/07/2021 02:33, Mike Schinkel wrote:
What I was disagreeing with is your assertion that "by definition"
deprecation must be followed with near-term removal.
I think we're talking past each other, and actually mostly agree, but
are mixing up two questions:
a) Does deprecation always
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
PHP 8.1.0alpha3 has just been released and can be downloaded from:
https://downloads.php.net/~ramsey/
Or use the git tag: php-8.1.0alpha3
Windows binaries are available at: https://windows.php.net/qa/
Please test it carefully, and report any bugs
On Wed, Jul 7, 2021, at 10:33 PM, Brent Roose wrote:
> > The property accessor RFC (which didn't get to a vote) discussed this, and
> > specifically proposed making properties part of the interface for...
> > basically all the reasons given here.
> >
>
> I thought the RFC didn't go to vote
On 07.05.2019 at 12:11, Nikita Popov wrote:
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
> 2. Many people think it is a security feature and use it as such. However,
> open_basedir is in reality a
> On 23 Jun 2021, at 8:42 PM, Kim Hallberg wrote:
>
> Hello internals,
>
> The RFC for the clamp function is now open and under discussion, you now have
> 2 weeks
> to discuss, suggest improvements and open issues before voting is considered.
>
> Any and all feedback is welcomed.
>
> The
> On 23 Jun 2021, at 8:42 PM, Kim Hallberg wrote:
>
> Hello internals,
>
> The RFC for the clamp function is now open and under discussion, you now have
> 2 weeks
> to discuss, suggest improvements and open issues before voting is considered.
>
> Any and all feedback is welcomed.
>
> The
Hi Dan,
that sounds reasonable. I have also updated the target to 8.2 and will wait
a big more to give everyone extra time.
Am Mi., 7. Juli 2021 um 18:13 Uhr schrieb Dan Ackroyd <
dan...@basereality.com>:
> On Tue, 6 Jul 2021 at 15:58, Michael Maroszek wrote:
> >
> > Dear internals,
> >
> > I
Hello Internals.
I mistakenly thought there was still time, but voting for a new RFC for PHP
8.1 has already closed.
I believe that an object-scoped random number generator is a necessity for
PHP and I will continue to work on it. We will continue to improve the RFC.
I will also work on getting
Le 07/07/2021 à 23:16, Larry Garfield a écrit :
The property accessor RFC (which didn't get to a vote) discussed this, and
specifically proposed making properties part of the interface for... basically
all the reasons given here.
My preference would be to add property accessors in 8.2 (at
> On 7 Jul 2021, at 23:16, Larry Garfield wrote:
>
> On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
>> Hi internals
>>
>> With the readonly properties RFC almost certainly accepted, I'd like to
>> discuss an idea that's slightly related to them.
>>
>> One of the problems that readonly
13 matches
Mail list logo
