[Proposal] Use Macroable trait on eloquent models

[imanghafoori1]

The fact that laravel packages (or laravel modules in other words) can not introduce new relations on the models that exist in the other modules *without touching their code) creates coupling problems.

For example if we have a commenting package which has a Comment model and some migrations to hold comments in a comments table.

when installed there is no way, except to expose a trait to put on the User model to reflect the relation between Comments and User. Ok this is not the end of the world, we can live with it.
We use the trait and $user->comments would be accessible.

But, when we add an other package to help us have like and dislike on the Comment model.
then how to put the trait on a model which already exists within the vendor folder ?!

From the theoretical point of view, this is violating the open-close principle.

For example, when you start to modularize your application with :
https://github.com/nWidart/laravel-modules
you immediately realize that models in different modules can not be totally decoupled.
When you add a add a comment module : the User module code should change to define new relations.
then when you add like module both the comment and user module code should be modified.

[imanghafoori1]

The problem is that the eloquent models support dynamic where clauses and __call() is already in use.
But that can be addressed. it is not a huge dilemma, I think.

[martinbean]

@imanghafoori1 In this instance, I’d expect a Comment model to be created in the application, then extends a package-provided model but then overrides/adds the methods I need.

I do this in an application I develop with Cashier’s Subscription model. I define a Subscription model in my application, extend Cashier’s, and then add a relation to plans that’s missing from Cashier’s version. If this were a comment model, I’d also be able to add traits to enable liking/disliking.

[imanghafoori1]

This does not solve the problem, does it ?! The goal is not to do that. Let me shed some light on it.
when we install the comment package, we do not want to put a trait on the User model to define a hasMany('Comment'... relation.

If you think about the tables. The users table does not need to change and is completely ignorant of the newly created comments table. (Only the comments table contains the user_id) So the comments table can come and go without the users table even realizing it.

We need almost the same thing for the models of these two tables.
Put this, within the comments package :
User::hasMany('comments', Comment::class, 'user_id');
then:
$user->comments will work.

Here the Comments package know and depend upon the user but user does not know anything or depend by any means upon the Comments

[martinbean]

when we install the comment package, we do not want to put a trait on the User model to define a relation

@imanghafoori1 Then how is your User model ever going to know it’s related to comments if you don’t define a relation? This is why packages like Cashier make you add a trait to your User model.

Put this, within the comments package: User::hasMany('comments', Comment::class, 'user_id');

I would not install a package that is modifying my application’s classes at runtime. What if my model isn’t called User? What if it isn’t in the App namespace like a fresh Laravel application?

You should always be in control of what a package is doing from your application. This is why things like service providers exist. A package should not be making assumptions on how things are structured in your application and what they’re called, and then modifying the behaviour of your application at runtime simply because you’ve installed it.

[imanghafoori1]

I am simplifying the example. I have thought about the idea for months and found all the answers, but it is not possible to describe everything here all at once.

What if my model isn’t called User?

You can put the full namespace of the User class in a config file of the comments package. laravel also does it in the auth.php

Then how is your User model ever going to know it’s related to comments if you don’t define a relation?

You define it in the comments service provider boot method.
User::hasMany('comments', Comment::class, 'user_id');

The name of the relation can also be configurable.

Also you may take a look at the way october cms has done this very nicely.

[michaeldyrynda]

Perhaps it best if you submit a PR to the framework with your proposal.

Seems like much discussion isn’t needed here.

If you have a good solution to this problem that will work in most situations, then let the code and accompanying PR speak for itself.

[imanghafoori1]

@michaeldyrynda Well, that doesn't work. The community should understand the need and vote for it.
Anyway I try to experiment with my thoughts.

If you look for examples you can take a look at october cms plugins.

[michaeldyrynda]

Well, I’m against the idea of a packaged modifying my app at run time like you’re suggesting. I’d much rather opt-in to the behaviour explicitly.

Sounds like your implementation is application-specific where you control both the app and the package; that’s cool, but implementing this in a useful way for the wider community I’d be interested in seeing.

Sounds like there’d be a lot of config just so you avoid using a trait to compose the desired behaviour - this is making assumptions about my app, namespaces, class names, etc.

[imanghafoori1]

@michaeldyrynda

Well, I’m against the idea of a packaged modifying my app at run time like you’re suggesting. I’d much rather opt-in to the behaviour explicitly.

It is not a modification of the app. laravel extensively uses the macroable trait. Is it a bad thing? The fact that a model can introduce a method on an other model does not mean that it affects the behavior of the other methods.
We need more decoupling. it's just that.

And let me mention that new modern languages like Go or Rust allow adding new methods to a type at language level.
You should define an struct and then add methods on it.
In other words, all the types are Macroable by default in those languages. In php we need some work around.

I do not want to copy/paste go-lang code here. You may google oop in go and see oop the concepts.

Do you think that the creators of those languages didn't know what they where doing ?! or there was a good reason for such a design?

[martinbean]

It is not a modification of the app. laravel extensively uses the macroable trait. Is it a bad thing?

@imanghafoori1 No, but Laravel uses the macroable trait so you can modify the framework; not so the framework or third-party packages have the ability to modify your application’s first-party code.

The fact that a model can introduce a method on an other model does not mean that it affects the behavior of the other methods.

I beg to differ. If a model is adding methods to other models in my application at runtime, then that can produce undesirable side effects if it’s overriding an already-defined method, and cause difficult-to-diagnose bugs that happen only at runtime.

And let me mention that new modern languages like Go or Rust allow adding new methods to a type at language level.
You should define an struct and then add methods on it.
In other words, all the types are Macroable by default in those languages. In php we need some work around.

It sounds like you want to write Go or Rust. Have you thought about using those languages if you feel they’re more appropriate?

Do you think that the creators of those languages didn't know what they where doing ?! or there was a good reason for such a design?

Laravel not copying another language’s paradigms is not saying those languages and their creators or wrong or “didn’t know what they [were] doing”. That’s simply a false dichotomy.

[Patryk27]

It's worth adding two cents to this discussion:

And let me mention that new modern languages like Go or Rust allow adding new methods to a type at language level.

Not exactly - at least Rust forbids frivolous implementations: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b82f7fc53c609572b76a3b7cec7928bc.

You can implement straight-away custom methods for types created by yourself and declared in your module only, so your case of having many modules fiddling with other modules' types would fail anyway.

What you can do is create a trait and then implement that trait for any other type (https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cf35cc82989eeef903c4c7389a61e9f5), but it's a completely different mechanism that does not affect the original type at all.

[imanghafoori1]

@Patryk27 Thank you for your exact investigation.
Of course, rust is by far the safest language of all time.

For eloquent models, whether we are going to affect the original behavior or not...
it depends on how we implement that "macroable" thing exactly.

[imanghafoori1]

I have had this problem in my mind around a couple of months or so.
But I think because this is new to you, it appears scary or somewhat monstrous. (like I was at first.)
Let the idea be in your mind for while, your brain will digest it in a background thread. 😉

[imanghafoori1]

After all, it just boils down not to violate the Liskov's substitution principle and the theory of types.

[imanghafoori1]

After reviewing the L in SOLID I found that adding a method to a type is proven to be harmless in theory,
as long as invoking that method does not weaken the invariants of that type, which does not seem to be the case for eloquent objects.

The problem can occur when we override a method. Overriding consists of
1- remove the current method
and
2- adding a new method with the same name.

The problem actually comes from removing .
So since the macroble trait does not allow overriding the host class methods, it is safe to be used.
and the resulting type would be a subtype.