Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » On abstract methods defined on traits »

On abstract methods defined on traits

php.internals

Pedro Magalhães

8 years ago
Hi internals, On the documentation about traits there is a mention to: "Traits support the use of abstract methods in order to impose requirements upon the exhibiting class." in https://secure.php.net/manual/en/language.oop5.traits.php#language.oop5.traits.abstract However, this is not true, and it has never been since traits were introduced (https://3v4l.org/tYAmu). There is a related bug report in https://bugs.php.net/bug.php?id=75449 What currently happens is that (like with normal methods), the method on the receiving class is used and the method from the trait is simply ignored. Although this can be fixed, I wanted your opinion on it as this would be the only thing from traits that would impose anything on the receiving class and conflicts with the normal precedence rules. Regards, Pedro

Christoph Becker

8 years ago
On 03.08.2018 at 19:08, Pedro Magalhães wrote:
> On the documentation about traits there is a mention to: "Traits support > the use of abstract methods in order to impose requirements upon the > exhibiting class." in > https://secure.php.net/manual/en/language.oop5.traits.php#language.oop5.traits.abstract > > However, this is not true, and it has never been since traits were > introduced (https://3v4l.org/tYAmu). > > There is a related bug report in https://bugs.php.net/bug.php?id=75449 > > What currently happens is that (like with normal methods), the method on > the receiving class is used and the method from the trait is simply ignored.
Yes. However, if the class using the trait would not implement the method, a compile time error would be thrown.
> Although this can be fixed, I wanted your opinion on it as this would be > the only thing from traits that would impose anything on the receiving > class and conflicts with the normal precedence rules.
Frankly, I don't understand what this bug report is about, <https://3v4l.org/38lmA> looks pretty much expected (note that the error message is totally different from what has been reported; there is no class D in the reproduce script).
-- Christoph M. Becker

Pedro Magalhães

8 years ago
On Fri, Aug 3, 2018 at 7:22 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 03.08.2018 at 19:08, Pedro Magalhães wrote: > > What currently happens is that (like with normal methods), the method on > > the receiving class is used and the method from the trait is simply > ignored. > > Yes. However, if the class using the trait would not implement the > method, a compile time error would be thrown. >
Not really, I mean, the error you get is that you are declaring an abstract method in a non abstract class. If the receiving class is abstract, this works as expected (https://3v4l.org/QdHBo) and nothing is imposed on the receiving class. I think this is also what Levi is referring to. (Correct me if I'm wrong)
> > Although this can be fixed, I wanted your opinion on it as this would be > > the only thing from traits that would impose anything on the receiving > > class and conflicts with the normal precedence rules. > > Frankly, I don't understand what this bug report is about, > <https://3v4l.org/38lmA> looks pretty much expected (note that the error > message is totally different from what has been reported; there is no > class D in the reproduce script). >
Yes, the report is not very clear. But if we follow the docs logic, A::values in your example should fail to compile as it doesn't have the same signature (return type) as the method from the trait T. Regards, Pedro

Christoph Becker

8 years ago
On 03.08.2018 at 20:47, Pedro Magalhães wrote:
> On Fri, Aug 3, 2018 at 7:22 PM Christoph M. Becker <cmbecker69@gmx.de> > wrote: > >> Frankly, I don't understand what this bug report is about, >> <https://3v4l.org/38lmA> looks pretty much expected (note that the error >> message is totally different from what has been reported; there is no >> class D in the reproduce script). > > Yes, the report is not very clear. But if we follow the docs logic, > A::values in your example should fail to compile as it doesn't have the > same signature (return type) as the method from the trait T.
Ah, now I see. Thanks! In other words, <https://3v4l.org/2pERT> is fine, but <https://3v4l.org/ouO0R> is not. I find that rather strange.
-- Christoph M. Becker

Levi Morrison

8 years ago
On Fri, Aug 3, 2018 at 11:09 AM Pedro Magalhães <mail@pmmaga.net> wrote:
> > Hi internals, > > On the documentation about traits there is a mention to: "Traits support > the use of abstract methods in order to impose requirements upon the > exhibiting class." in > https://secure.php.net/manual/en/language.oop5.traits.php#language.oop5.traits.abstract > > However, this is not true, and it has never been since traits were > introduced (https://3v4l.org/tYAmu). > > There is a related bug report in https://bugs.php.net/bug.php?id=75449 > > What currently happens is that (like with normal methods), the method on > the receiving class is used and the method from the trait is simply ignored. > > Although this can be fixed, I wanted your opinion on it as this would be > the only thing from traits that would impose anything on the receiving > class and conflicts with the normal precedence rules. > > Regards, > Pedro
It's partly true; an abstract method in a trait will require that the using class to have a method of the same name but nothing else. In my opinion the docs should be changed, not trait behavior.