On Sat, May 2, 2020 at 9:13 PM Ben Ramsey wrote:
> > On May 2, 2020, at 13:57, AllenJB wrote:
> >
> > Hi all,
> >
> > I'd like to discuss deprecating uniqid()
> >
> > I believe it's dangerously bad a doing "what it says on the tin". New
> developers still reach for it and do not read the warning
> On May 2, 2020, at 14:13, Ben Ramsey wrote:
>
>> On May 2, 2020, at 13:57, AllenJB wrote:
>>
>> Hi all,
>>
>> I'd like to discuss deprecating uniqid()
>>
>> I believe it's dangerously bad a doing "what it says on the tin". New
>> developers still reach for it and do not read the warnings o
> On May 2, 2020, at 13:57, AllenJB wrote:
>
> Hi all,
>
> I'd like to discuss deprecating uniqid()
>
> I believe it's dangerously bad a doing "what it says on the tin". New
> developers still reach for it and do not read the warnings on the manual page
> (or if they do, don't fully understan
Hi all,
I'd like to discuss deprecating uniqid()
I believe it's dangerously bad a doing "what it says on the tin". New
developers still reach for it and do not read the warnings on the manual
page (or if they do, don't fully understand how bad it is).
For older codebases that still rely on i
It will make "attribute" a reserved keyword, which caused more BC break
comparing to Attribute class.
Regards,
CHU Zhaowei
-Original Message-
From: Aleksander Machniak
Sent: Sunday, May 3, 2020 1:38 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Renaming PhpAttribute to Attribut
Hi Tyson,
For `opcache.jit_optimization_level` I think we'd better remain these magic
numbers, like what we did for `opcache.optimization_level`.
I think this kind of setting requires professional knowledge in this domain,
and it doesn't make much sense to change to the text-based
Options. E.g.
On 02.05.2020 18:02, Benas IML wrote:
> From my standpoint, I don't really believe we can remove it. As without it,
> any class would be considered as an attribute - even one that isn't
> supposed to be.
I don't remember if it was considered, but... why not define attributes
with "class attribute
> Davey Shafik wrote:
>
>> I believe that using the PHP namespace is the right way to go, and look
>> forward to seeing code like this in the future:
>>
>> > namespace Dshafik;
>>
>> use PHP\Attribute;
>>
>> <>
>> class Foo { }
> Chase Peeler wrote:
>
>> I don't think PhpAttribute is a bad n
Hello,
You should ask Benjamin this question as he is the Attributes RFC author.
>From my standpoint, I don't really believe we can remove it. As without it,
any class would be considered as an attribute - even one that isn't
supposed to be.
Best regards,
Ben.
On Sat, May 2, 2020 at 5:57 PM Niklas Keller wrote:
> Hey Benas,
>
> a question has come up whether we even need the PhpAttribute /
> Attribute attribute at all. We could prevent any conflict if we just
> delete it.
>
> Best,
> Niklas
>
We need Attribute so static analysis tooling and IDEs can c
Hey Benas,
a question has come up whether we even need the PhpAttribute /
Attribute attribute at all. We could prevent any conflict if we just
delete it.
Best,
Niklas
Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML
:
>
> Hey internals,
>
> Since it's safe to say that the Attributes v2 RFC h
Hi Benjamin,
> > I think it would be best to split up opcache.jit into five separate
> > configuration directives and propose the following names:
> >
> > * opcache.jit for (de)activating JIT
> > * opcache.jit_optimization_level for setting the optimization level
> > * opcache.jit_trigger for conf
Thank you guys for all your feedback!
It's a big surprise for me that so many people love PHP for this style of
referring.
Sure, I am out of the pack. I am stuck to PHP due to my activity type and
mostly write a lot of code no one reads except me.
I have found my own way to deal with it. Mostly P
On 2 May 2020 08:23:14 BST, Davey Shafik wrote:
>IMO, the onus of proof should be on those wishing to introduce a change
>that has a potential conflict, not those trying to prevent one.
While I totally understand the principle here, it does lead to two questions:
1) What evidence would you acce
On Tue, Apr 14, 2020 at 3:53 PM Sebastian Bergmann
wrote:
> PHP 8's JIT is currently mainly controlled through the opcache.jit
> configuration directive [1].
>
> The value for opcache.jit is currently a sequence of four digits, "5021"
> for instance. This would activate JIT optimizations based on
On Wed, Apr 29, 2020 at 08:24 Benas IML wrote:
> Hello,
>
> > Again, your assumption that just about everyone uses namespaced classes
> > doesn't take into account closed source projects. I don't care if it's a
> major
> > release or not - BC breaks should always be avoided without a major
> bene
16 matches
Mail list logo
