Hey Pedro,
On Mon, Jun 8, 2020 at 5:59 PM Pedro Magalhães wrote:
> On Wed, May 27, 2020 at 12:07 AM Pedro Magalhães wrote:
>
>> On Tue, May 26, 2020 at 3:46 PM Marco Pivetta wrote:
>>
>>> Considering that, as far as I know, only the constructor remains
>>> "special".
>>>
>>
>> Leaving the
On Wed, May 27, 2020 at 12:07 AM Pedro Magalhães wrote:
> On Tue, May 26, 2020 at 3:46 PM Marco Pivetta wrote:
>
>> Considering that, as far as I know, only the constructor remains
>> "special".
>>
>
> Leaving the special case only for constructors instead of all magic
> methods sounds better
On Wed, May 27, 2020 at 8:23 AM Alexandru Pătrănescu
wrote:
> In terms of what final does to a private method, as I understand, it will
> just be ignored everywhere? (except for constructor)
> I mean, final deny overriding but private methods cannot be overridden by
> design. We should have that
On Wed, May 27, 2020 at 2:08 AM Pedro Magalhães wrote:
> On Tue, May 26, 2020 at 3:46 PM Marco Pivetta wrote:
>
> > Considering that, as far as I know, only the constructor remains
> "special".
> >
>
> Leaving the special case only for constructors instead of all magic methods
> sounds better
On Tue, May 26, 2020 at 3:46 PM Marco Pivetta wrote:
> Considering that, as far as I know, only the constructor remains "special".
>
Leaving the special case only for constructors instead of all magic methods
sounds better to me. Right now, that sounds like a winning compromise for
the RFC. It
Hey Pedro,
On Tue, May 26, 2020, 16:34 Pedro Magalhães wrote:
> Hi Marco,
>
> Thanks for the feedback.
>
> About the sealed type example, it is true that `final protected` wouldn't
> achieve the same thing. But as an attempt to provide an alternative design,
> wouldn't an union type of the
Hi Marco,
Thanks for the feedback.
About the sealed type example, it is true that `final protected` wouldn't
achieve the same thing. But as an attempt to provide an alternative design,
wouldn't an union type of the desired children be a better choice?
I can see some usefulness in it but IMHO, it
Hey Bruce,
On Fri, May 22, 2020, 22:07 Bruce Weirdan wrote:
>
> On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote:
>
>> Overall, this RFC breaks some design capabilities that are within the
>> language, specifically around `__`-prefixed methods in the language.
>
>
> Wouldn't your use cases
On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote:
> Overall, this RFC breaks some design capabilities that are within the
> language, specifically around `__`-prefixed methods in the language.
Wouldn't your use cases be covered by `protected final` though, as proposed
by Pedro?
--
Best
Hey Pedro,
On Fri, May 22, 2020 at 5:43 PM Pedro Magalhães wrote:
> Hi internals,
>
> I want to put up for discussion an RFC (
> https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
> remove some inappropriate signature checks that are still done on private
> methods. Namely,
Hi internals,
I want to put up for discussion an RFC (
https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
remove some inappropriate signature checks that are still done on private
methods. Namely, those checks are:
- When a method has the same name as a parent's final private
11 matches
Mail list logo
