Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118652
MIME-Version: 1.0
References: <67365E50-D383-4B5F-B8E9-95AC2E136223@getmailspring.com>
In-Reply-To: <67365E50-D383-4B5F-B8E9-95AC2E136223@getmailspring.com>
Date: Sun, 18 Sep 2022 13:05:30 -0700
Message-ID: <CAMrTa2Eiut7jis9GeAqSjBF8DyfBeSBY3pih6MGqK_3Vo1-21g@mail.gmail.com>
To: Mohammad Amin Chitgarha <machitgarhaa@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a4f9bb05e8f91ee6"
Subject: Re: [PHP-DEV] Specify abstract parent methods for traits
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000a4f9bb05e8f91ee6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 18, 2022 at 4:51 AM Mohammad Amin Chitgarha <
machitgarhaa@gmail.com> wrote:

> Hi.
>
> 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 paren=
t
> 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 classe=
s.
>
> Stick with parent:: in the trait function. Implicit and not good (e.g.
> static analyzers and IDEs cannot help).
>
> Change the parent class to use traits. This is not always possible, as it
> might be someone else's code.
>
> Ignore this please: copy and paste the method all over the place.
>
> It's also not possible to use things like insteadof or as when including
> the trait.
>
> Here, I want to propose the concept of explicitly declaring the parent
> method. The way to achieve this is to use attributes for trait functions,
> e.g. #[Override].
> It has the advantage of not requiring the redeclaration of the parent
> method as abstract. However, it should be not allowed to use as clause wh=
en
> including the trait function, as it's against the definition of overridin=
g
> a method (i.e. it must have the same name and visibility).
> Another method is using a new parent specifier (i.e. abstract parent
> public function =E2=80=A6), and is more (?) consistent with the current b=
ehaviour.
> However, it requires duplicating the parent method signature.
> There could be methods using insteadof or as, but they has nothing to do
> with the trait itself, and doesn't fix the problem of implicit declaratio=
n
> of the parent method in the trait.
> Thanks,
> Mohammad Amin Chitgarha.
>

I can't quite understand what it is you want to accomplish. To make traits
work better with parent classes of the classes they are used in?

If so, my answer would be that traits aren't supposed to be used in that
way in the first place, so any difficulty in doing so isn't a problem to be
fixed. A trait should, in theory, (in my own opinion) be able to be used in
any class, regardless of semantic correctness. That is, it should not
produce compile time or run time errors related to class structure no
matter what class it is used on. If a trait fails that test, it is a misuse
of the feature in my opinion, and changes to traits that delay that error
reporting are not beneficial in my opinion.

This is just trying to use traits to make PHP multiple inheritance, but the
PHP object model is fundamentally single inheritance. If you want to move
PHP towards multiple inheritance, my preference would be to actually do
*that* instead of making traits even more difficult and dangerous to use
correctly.

Jordan

--000000000000a4f9bb05e8f91ee6--