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 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-trait-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.
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 when including the trait function, as it's against the definition of overriding 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 …), and is more (?) consistent with the current behaviour. 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 declaration of the parent method in the trait.
Thanks,
Mohammad Amin Chitgarha.
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 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-trait-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.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 when
including the trait function, as it's against the definition of overriding
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 …), and is more (?) consistent with the current behaviour.
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 declaration
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
I am also confused about this. Are you trying to generate multiple
inheritance with this? If not ... can you provide code examples of the
problem and a a hypothetical code of the solution you propose to that
problem?
Thanks
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 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-trait-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.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.
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