Hi
On 5/11/23 18:37, Tim Düsterhus wrote:
I'm now opening discussion for the RFC "Marking overridden methods
(#[\Override])":
RFC: Marking overridden methods (#[\Override])
https://wiki.php.net/rfc/marking_overriden_methods
Proof of concept implementation is in:
On 4 June 2023 15:12:29 BST, "Tim Düsterhus" wrote:
>It's anecdata, but the attribute would have saved me debugging effort several
>times in the past year - that's the whole reason I'm proposing it. It also
>saved me time in other language that have the feature already built-in.
Fair enough. I
Hi
On 5/30/23 14:17, Rowan Tommins wrote:
On 29/05/2023 19:29, Tim Düsterhus wrote:
I think this is a flawed premise: Any sort of analysis that PHP itself
performs can also be performed in userland.
This isn't actually true. There is a lot of dynamic functionality in PHP
where correctness
Hi
On 5/29/23 21:34, Claude Pache wrote:
One weakness of the proposal, is that there is no notice when a method without
#[\Override] annotation accidentally overrides a parent method. This is
necessary for the sake of BC, of course. Therefore, (inspired by the
--noImplicitOverride flag of
Hi Tim
On 5/11/23 18:37, Tim Düsterhus wrote:
> Hi
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
>
>
> RFC: Marking overridden methods (#[\Override])
> https://wiki.php.net/rfc/marking_overriden_methods
>
> Proof of concept implementation is
On 29/05/2023 19:29, Tim Düsterhus wrote:
I think this is a flawed premise: Any sort of analysis that PHP itself
performs can also be performed in userland.
This isn't actually true. There is a lot of dynamic functionality in PHP
where correctness can't be proven ahead of time, and run-time
> Le 11 mai 2023 à 18:37, Tim Düsterhus a écrit :
>
> Hi
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
>
>
> RFC: Marking overridden methods (#[\Override])
> https://wiki.php.net/rfc/marking_overriden_methods
>
Hi Tim,
One weakness of
Hi
On 5/23/23 17:47, Sara Golemon wrote:
I think targeting 8.3 is aggressive as we're less than a month from FF
(accounting for discussion and voting period).
I didn't expect the proposal to need much of a discussion, as the
functionality is known from existing programming languages and the
Hi
On 5/27/23 23:10, Rowan Tommins wrote:
So the argument is that the key estimate for whether to include it in the
engine is how many users will add the attribute, but not run a static analysis
tool. If that number is very low, adding it to the engine has a very low value.
As mentioned in
Hi
On 5/24/23 01:32, David Gebler wrote:
where you're coming from, however I'd refer back to my earlier comment: any
attributes added in the engine should provide a tangible benefit which
*can't be achieved in userland*.
I think this is a flawed premise: Any sort of analysis that PHP itself
On 27 May 2023 11:40:44 BST, Dan Ackroyd wrote:
>On Mon, 22 May 2023 at 22:32, David Gebler wrote:
>>
>> either you use static analysis tools as part of your PHP workflow, because
>> you care about that stuff, or you don't.
>
>I these words imply an unpleasant connotation; that people who don't
On Mon, 22 May 2023 at 22:32, David Gebler wrote:
>
> either you use static analysis tools as part of your PHP workflow, because
> you care about that stuff, or you don't.
I these words imply an unpleasant connotation; that people who don't
use static analysis tools are bad people who don't
On Tue, May 23, 2023 at 9:27 PM Tim Düsterhus wrote:
> Just to make sure there is no misunderstanding I'd like to clarify that
> the proposed check of this RFC is not a runtime error. It's a compile
> time error, just like the check for incompatible method signatures
> during inheritance. In
On Tue, May 23, 2023, at 10:47 AM, Sara Golemon wrote:
> On Thu, May 11, 2023 at 11:37 AM Tim Düsterhus wrote:
>>
>> I'm now opening discussion for the RFC "Marking overridden methods
>> (#[\Override])":
>>
>
> I 100% get the intent behind this RFC, and as someone who's used this in
> multiple
Hi
On 5/22/23 23:32, David Gebler wrote:
whether there's an appetite out there in general to start adding all sorts
of new runtime checks, which I would argue means any new runtime check
warrants the utmost consideration of cost-benefit.
Just to make sure there is no misunderstanding I'd like
On Thu, May 11, 2023 at 11:37 AM Tim Düsterhus wrote:
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
I 100% get the intent behind this RFC, and as someone who's used this in
multiple other languages the benefit to defensive coding is obvious.
On Mon, May 22, 2023 at 1:01 PM Dan Ackroyd wrote:
> Even for those who use static analysis, most (afaik) don't have it
> running constantly in local development and this RFC would prevent
> people wondering why their code is behaving surprisingly before it is
> static analysed.
>
It takes care
Hi Tim
On Thu, May 11, 2023 at 6:37 PM Tim Düsterhus wrote:
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
> RFC: Marking overridden methods (#[\Override])
> https://wiki.php.net/rfc/marking_overriden_methods
We've already talked in private, but let me
Amazing wording Dan: great way to drive people away. YIKES.
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Mon, 22 May 2023 at 13:49, Dan Ackroyd wrote:
> On Thu, 18 May 2023 at 09:12, Marco Pivetta wrote:
> >
> > I am not sure this RFC is really relevant...
On Mon, 22 May 2023 at 12:49, Dan Ackroyd wrote:
>
> So one should be able to see there is interestunless of course
> someone is so bad at basic human empathy, that they can't accept other
> people's lived experiences as valid, and will only accept something as
> 'good programming practice'
On Sat, 20 May 2023 at 18:58, David Gebler wrote:
>
> this is exactly the kind of check which you would
> expect to be done at the static analysis stage
Even for those who use static analysis, most (afaik) don't have it
running constantly in local development and this RFC would prevent
people
On Thu, 18 May 2023 at 09:12, Marco Pivetta wrote:
>
> I am not sure this RFC is really relevant... Would it perhaps
> make sense to have this in userland first, in phpstan or psalm
> plugins, to see if there is interest?
The RFC lists other languages where an equivalent is available, and we
can
On Thu, May 18, 2023 at 9:12 AM Marco Pivetta wrote:
>
> Would it perhaps make sense to have this in userland first, in phpstan or
> psalm plugins, to see if there is interest?
>
100% this in my view; this is exactly the kind of check which you would
expect to be done at the static analysis
Hey Tim,
On Thu, 11 May 2023, 18:37 Tim Düsterhus, wrote:
> Hi
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
>
>
> RFC: Marking overridden methods (#[\Override])
> https://wiki.php.net/rfc/marking_overriden_methods
>
> Proof of concept
Hi
On 5/16/23 18:17, Dan Ackroyd wrote:
I'm now opening discussion for the RFC "Marking overridden methods
(#[\Override])":
This RFC is probably a good idea, even if the number of people who
will benefit from the behaviour in the engine might be quite low. My
guess is the number of people
On Thu, 11 May 2023 at 17:37, Tim Düsterhus wrote:
>
> Hi
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
This RFC is probably a good idea, even if the number of
Hi
I'm now opening discussion for the RFC "Marking overridden methods
(#[\Override])":
RFC: Marking overridden methods (#[\Override])
https://wiki.php.net/rfc/marking_overriden_methods
Proof of concept implementation is in:
https://github.com/php/php-src/pull/9836
Thanks to
27 matches
Mail list logo
