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
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.abstractHowever, 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
On Fri, Aug 3, 2018 at 7:22 PM Christoph M. Becker cmbecker69@gmx.de
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
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
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.abstractHowever, 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.