Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118712
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <67365E50-D383-4B5F-B8E9-95AC2E136223@getmailspring.com>
Date: Fri, 30 Sep 2022 01:34:10 -0400
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0173F88D-D26F-4C97-9219-074380946BC3@gmail.com>
References: <67365E50-D383-4B5F-B8E9-95AC2E136223@getmailspring.com>
To: Mohammad Amin Chitgarha <machitgarhaa@gmail.com>
Subject: Re: [PHP-DEV] Specify abstract parent methods for traits
From: mike@newclarity.net (MKS Archive)

> On Sep 18, 2022, at 7:51 AM, Mohammad Amin Chitgarha =
<machitgarhaa@gmail.com> wrote:
>=20
> Hi.
>=20
> Currently, it's possible that, inside a trait's function, use the =
parent method of a class using the trait. This way, not only it's =
implicitly supposed the trait is used in a class having a parent, but =
also the parent class has such a method. It doesn't seem to be a good =
practice, as stated in the answers of this question =
(https://softwareengineering.stackexchange.com/questions/371067/should-a-t=
rait-refer-to-parent-methods).
> Also, it's almost impossible to override a parent method (using the =
same signature) using a trait. This is useful if you have to inherit =
multiple classes from a base class, but also override one (or more) of =
the base methods with a common functionality provided by a trait.
> There are some workarounds to these problems (specially talking about =
the later one), but they have their own disadvantages:
> Define a trait function with the same signature but a different name =
and use it. The main disadvantage is that it's a different method, and =
is not polymorphic.
> Do (1), include the trait in the derived class(es), then override the =
parent method in all derived classes and manually call the trait =
function. Not perfect because you have to copy the same code for all =
derived classes.
>=20
> Stick with parent:: in the trait function. Implicit and not good (e.g. =
static analyzers and IDEs cannot help).
>=20
> Change the parent class to use traits. This is not always possible, as =
it might be someone else's code.

How often have you (or anyone else?) found a need to inherit someone =
else's class and then need to override one of their methods via a trait? =
A need that you felt you could not easily work around in some other =
reasonable way?

If yes, could you please give some examples?

-Mike