Re: [VOTE] Remove inappropriate inheritance signature checks on private methods

On Tue, Jun 16, 2020 at 10:19 AM Marco Pivetta <ocramius@gmail.com> wrote: > On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov <nikita.ppv@gmail.com> > wrote: > >> The original RFC could at least >> make a consistency argument, but the final form, which converts an >> existing >> special case into an even more convoluted special case, can not. Why is >> __construct() exempted, but __clone() for example isn't, even though >> similar considerations apply to it? >> > > While private final function __construct() prevents child > classes from > making the constructor open, or accessing it (important for abstract > types), protected final function __clone() achieves the same > without > having to rely on the private visibility modifier ( > https://3v4l.org/psR5F, for example). > In my opinion, the example given by Marco on the discussion thread about sealed types is a good argument on why __construct should keep the behavior (https://externals.io/message/110251#110255). You would need to write a lot of convoluted code to achieve the same behavior as you currently can. It is true that cloning is then possible from within a subtype, which is > indeed a bit of a problem: https://3v4l.org/qupHR > I don't find that problematic. If ultimately your goal is to disallow cloning, doing it by visibility constraints is cheaper and covers 99% of the cases but it's still possible to enforce it even for the child class by throwing: https://3v4l.org/U1LMQ Regards, Pedro