Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110280
Return-Path: <ocramius@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 96301 invoked from network); 26 May 2020 16:06:23 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
by pb1.pair.com with SMTP; 26 May 2020 16:06:23 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
by php-smtp4.php.net (Postfix) with ESMTP id 34D321804DA
for <internals@lists.php.net>; Tue, 26 May 2020 07:46:36 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level:
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS
autolearn=no autolearn_force=no version=3.4.2
X-Spam-ASN: AS15169 209.85.128.0/17
X-Spam-Virus: No
X-Envelope-From: <ocramius@gmail.com>
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by php-smtp4.php.net (Postfix) with ESMTPS
for <internals@lists.php.net>; Tue, 26 May 2020 07:46:35 -0700 (PDT)
Received: by mail-io1-f50.google.com with SMTP id q8so20846344iow.7
for <internals@lists.php.net>; Tue, 26 May 2020 07:46:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc;
bh=29idKXrjCIFB6K2+REOu6XYCJoj2Zi5E+r3f5wrvkbY=;
b=oKyIoesBpAixCIKd3MVIZmCFKouEezQtr+LWH2sEg6EohiuZrOYi6YKueGBSR/HZpe
22db17d70IMUctYJa2yZG70sj075PgSxicM5CoTvU36V9pxncMrHX93flJ0vzjDkjbqP
UghBAEpREzY0/E0NhyASsWmHxCKd6k3WCWkavrgiZIcS6kFAMAZGLck3SDhl3dehtKTX
6DkAZwqz5I6BkIiLdVQqbA+OiN/cuqXwwYRpi9c2mNthEr9eIG6qd+Rq2c0Oq8uZyM4t
1SCSx9EPnQsREwVqH1bAsoqgjWNOAWz4zqRdA+t2iftQM53V5DGb8wu7/78/2KhdRyE3
6MxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=29idKXrjCIFB6K2+REOu6XYCJoj2Zi5E+r3f5wrvkbY=;
b=cLDyxSsxfS/0ZTNYVSDzPmX9xatf9rt9DE0MOv0amT8PAk21QwnDtWoUPHVhgiQy8F
gn+lGcKTt7ko02nwXe5Q2cs6hyPzCt16NueifOYNHqU7P6Z1fR+Vn7rdPUGw4vZakmUK
DeRyNXmBQczHVeu6JZxnA0wkNdqZ7FnoPbd1UaLGchxitQqAEoP+P3SBCxEi/y7jAhEa
hdpvI59DLVV/xO+5Kyo4aAs0dIi2cLcyrhcTBAHc/8hdrZB1QytveGtSgt2dBc39wlQS
0PJw6biCMneSgt4+RZSmbVlAbo3YUK61ZQyt9SBjxbEK4vUPYNeI43LJk5hCEsTD55uK
6Szw==
X-Gm-Message-State: AOAM530ti/TR9ph6hzio8wUtwsJTf44x16PE9ARUgxGwbPdqZn4dW7Vj
1E1e94JQ0bg7eUXojpXCKQDb0oAGE4FQQWLg+KzadaQy
X-Google-Smtp-Source: ABdhPJx2o7IGY8xc/b7jOYJYAjuN2nb1IFEZCRmdK+XKFz743WH+UksTxaY9HwPgy4KQZGoa4MpMEJTyZlNmmuxEvUo=
X-Received: by 2002:a02:a681:: with SMTP id j1mr1311519jam.13.1590504395176;
Tue, 26 May 2020 07:46:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAJd4=YZd3Mh8sQjYxE-YfNim-CN1+j8oST2W+nykXDynC_KQiA@mail.gmail.com>
<CADyq6sKn7ERUTmHfOSt6bOeWvFiS33ciaK7WZuLgktCs7AN3zg@mail.gmail.com> <CAJd4=YYt46c4tyuaRxgv6VTrerSZsNG-G4OUYEHPPrLOEYDSew@mail.gmail.com>
In-Reply-To: <CAJd4=YYt46c4tyuaRxgv6VTrerSZsNG-G4OUYEHPPrLOEYDSew@mail.gmail.com>
Date: Tue, 26 May 2020 16:46:22 +0200
Message-ID: <CADyq6sK8tJnV9igmeogcoGOHhVS=84R4V37KoDy15K-1xo49pg@mail.gmail.com>
To: =?UTF-8?Q?Pedro_Magalh=C3=A3es?= <mail@pmmaga.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007d010c05a68e2945"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance
signature checks on private methods
From: ocramius@gmail.com (Marco Pivetta)
--0000000000007d010c05a68e2945
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hey Pedro,
On Tue, May 26, 2020, 16:34 Pedro Magalh=C3=A3es <mail@pmmaga.net> 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 desig=
n,
> wouldn't an union type of the desired children be a better choice?
>
Difficult without having type aliases for union types: possible with tools
like psalm, but fragile and easy to work around for less experienced devs.
The construct in my example is instead very hard to avoid unless you know
about `ReflectionClass#newInstanceWithoutConstructor()`
it is supported by a broken behavior
>
Not really: the `__`-prefixed methods are indirectly part of the object's
API, and I seal them off by design, guiding consumers of my implementation
& type.
About lifting the restriction only to magic methods, I don't really like
> that approach. Anything that makes them more special feels like a step in
> the wrong direction. If we were to lift that restriction, I would say tha=
t
> it should be lifted for any method, leaving the RFC to deal only with the
> static and abstract cases.
>
Magic methods are indeed a pain in the language: I'm trying to make the
best use for them (there's already enough bad usage out there).
About the serialization example, I think that goal is equally possible to
> achieve with final protected.
>
Good point!
Considering that, as far as I know, only the constructor remains "special".
>
--0000000000007d010c05a68e2945--