Add decorators for eloquent models

[diegogit03]

I thinking on this:

class User extends Model {
    #[Column]
    public int $id;

    #[Column]
    public string $name;

    #[HasOne(Profile::class)]
    public Profile $profile;
}

Motivation:

It's more elegant and i think that can help with intelisense but it's not confirmed yet.

Problems:

• Maybe a breaking changes (i dont deep in the code yet)

References:

• Doctrine ORM
• Adonisjs Lucid

[ghost]

Hi. This should NOT be the default.

public function relation(): HasMany | HasManyThrough
{
   if ($this->exists() && $this->parent_id !== null) {
      return $this->hasManyThrough(.....
    }
    return $this->hasMany(....
}


Or


return $this->hasMany(...)->where('column', 'text');

The Attributes are restricting the functionality and generating parallel code interpreting.... bad Idea from my point of view.
If Laravel goes on the road of symfony with these annotated Attributes, I will be forced to fork an older version of laravel and maintain it my self....

Analog for declaring properties in the model. OOP exageration that generates waste of money on codding... Symfony way again...

[Sophist-UK]

When dynamic and more complex constructs are not needed, static/constant expressions are usually preferred, because they don't need to be calculated at runtime, something, static code analysis can benefit from. Also, especially, the way, attributes are written, their naming could result in self-explanatory annotations to the method that can abstract away implementation details the developer doesn't necessarily need to know or worry about.

Actually, whilst this is true in the most general and abstract case, in this specific instance I would argue the opposite is true. Using PHP attributes, you would either need to call the reflection API on every lookup or cache the values, and so at best this is going to be no faster than setting the values once with a method call, and at worse significantly worse.

[shaedrich]

@Sophist-UK There's the danger of that, yes. But this way, the static/constant expression style would be required when used this way, so that would be the only way (if not used dynamically) to implement it and the part, the user has to take care of. As for the rest, we should assume, the one writing the package is (hopefully) more experienced than the average developer using it, so they should take care of caching and efficient code. So, ideally, this should be slightly more fool-proof.

[Sophist-UK]

In the end it doesn't matter. I can't see Taylor wanting to support two alternative approaches forever, so unless there is an exceptionally good reason to switch to PHP attributes from current methods, so good that forcing users to put all existing code-bases through a migration (even if over several major versions of Laravel), then this debate is a bit pointless.

However, I think that if you can make the case to the community that this pain is worthwhile and get some good degree of community consensus that this is so, then he might well consider it.

[henzeb]

Indeed.in the mean time, feel free to create a package, Taylor would say ...

[shaedrich]

However, I think that if you can make the case to the community that this pain is worthwhile and get some good degree of community consensus that this is so, then he might well consider it.

Oh, I think, unless you are a friend of Taylor, hoping to get a PR approved, is rather pointless.

[shaedrich]

I used a similar approach, however, not by annotating properties but the model itself, since the columns are technically not on the model but on $this->attributes.

[smares]

I think that laravel can support both approaches i dont know why not

Because it's a PITA as developer having to look in multiple places what is happening and Laravel already includes a lot of "magic".

[diegogit03]

What is PITA?

Sorry I am a beginner English speaker

[Sophist-UK]

Pain In The Ass.

[diegogit03]

LOL

[diegogit03]

Okay guys i read all replies and

Possible problems of this implementation:

• Migration of code base (but i think that we can TRY keep all compatible)
• Add more complexity (i dont agree with this)

Possible motivations:

• More elegant syntax (relative)
• Possible intelisense improvements (possibility)

With this conclusions the best solution FOR NOW is make a package . In my opinion, if the generic RFC passes, we could go deeper into this discussion again.

[smares]

That RFC is 8 years old and originally targeted PHP 7.1. Any specific reason why you mention it?

[diegogit03]

With generics decorators approach can make more sense, like adonisjs make(it's typescript)

[ghost]

Hi. That RFC was dis-considered anyway because it is easier to write like this:

class A
{
    public function __construct(protected string $x, protected Carbon $c)
    {
    }
}

$a = new A('aaa', new Carbon())

vs

class Entry<KeyType, ValueType>
{
    protected $key;
    protected $value;
 
    public function __construct(KeyType $key, ValueType $value)
    {
        $this->key  = $key;
        $this->value = $value;
    }
}

$entry = new Entry<int,string>(1, 'test');

The only thing kept from that RFS was:

/**
 * @param Collection<Model> $models
 */
pubic function x(Collection $models)

Which I find useful.