[Eloquent] Allow multiple traits to "extend" methods like getAttribute()

[filippotoso]

Hi,

today I encountered this issue using awobaz/compoships in a model that already used one of my traits. Both overrode the getAttribute() method.

Trait method getAttribute has not been applied, because there are collisions with other trait methods on App\Models\Ticket

I though this could be elegantly solved implementing a solution in the same way Model::bootTraits() handles traits initialization.

Is this something you'll consider?

Thanks

P.S.
For optimization purposes an array property could be defined to specify which methods can be overwritten.

[rojtjo]

I don't see how that would work since it would fail before you're even able to call a method. I think the only option you have in this case is to use the insteadof or as operator when using your traits to resolve the conflict.

See: https://www.php.net/manual/en/language.oop5.traits.php#language.oop5.traits.conflict

[filippotoso]

Model::bootTraits() defines a convention for traits initalization: 'initialize'.class_basename($trait) (and also for boot)

You create a initializeYOU-TRAIT-NAME method and Laravel calls it on initialization.

The same can be implemented for getAttribute() and other methods that are commonly overwritten by packages.

Laravel can define a convention like: when you need to overwrite the Model::getAttribute() method in your traits, create a getAttributeYOU-TRAIT-NAME and we'll call it for you.

When Model::getAttribute() is called, Laravel checks for traits methods (maybe cached in an array at startup for speed) and if it finds the rights methods, calls them one by one untill one of them returns a value. If no trait method returns a value, the original behavior is executed.

[rojtjo]

I totally misunderstood your suggestion earlier, this makes way more sense. Thanks for exaplaining!

I wonder how you would handle different priorities?
Say getAttributeX for some reason always returns a default value, but you actually want the result of getAttributeZ.

(I'm assuming class_uses_recursive always returns the traits in alphabetical order for this example which is probably not the case, but conflicts like this could still happen)

[filippotoso]

If the conflict is at the attribute name level (in other words, the same $key parameter returns different values from different traits), the traits behaviors are most probably not compatible (ie. the packages that contain them have incompatibility issues) and even if the priority issues are solved perfectly, the behavior will not be the expected one.

In all the cases I have seen, the traits handles a specific use case. For instance Compoships checks if the $key parameter is an array. If it's not, the parent method is called. The same applies to my own traits. I usually check for a specific condition (ie. the $key parameter ends with a "_label" string) and then revert back to the parent method.

The convention should be that, in the case the trait doesn't handle the specific use case, it should not return a default value.
Laravel will cycle all the traits and then return the first valid one it finds or follow its own default behaviour.

This is just a proposal to see if there's interest. If this is the case I'll check more packages to find out how getAttribute() is overwritten and understand all the possible uses cases.