New accessor/mutator syntax and return type hinting

[mishavantol]

Since Laravel 8 we can use the new Attribute syntax when creating accessors and/or mutators. Which look quite nice in my opinion.

But there's one disadvantage, our current codebase is strictly typed, as it should be nowadays. And where I can simply add a return type in the old syntax, there's no way of letting the IDE and/or static analyzers know what comes out of these new method. Or, to be precise, we do know what comes out, it's an Attribute object.

To be honest, the first example will be probably used in the code as $this->some_calculated_value, and for that to work in Phpstorm we already need a plugin (e.g. Laraval Idea) to hint this correctly.

I'm just curious to other people's thoughts about dealing with these type hinting issues in a framework like Laravel which uses some magic under the hood.

[Angel5a]

For IDE you can use doc-blocks. Static analyzers also can use this hints, but you become fully responsible in consistence of declared type and actually returned value type. Yes, this is disadvantage of new syntax, but all the Laravel have been written this way (a box full of magic) long time ago.

/**
 * @property-read int $some_calculated_value
 */
class A extends Model
{
    //...
    protected function someCalculatedValue(): Attribute
    {
        return Attribute::make(get: static fn () => 123);
    }
}

[shaedrich]

Maybe, a method-level doc-block using Generics could be better 🤔

/**
 * @return Attribute<int>
 */
protected function someCalculatedValue(): Attribute
{
    return Attribute::make(get: static fn() => 123);
}

[Angel5a]

Common IDE doesn't know about Laravel specific magic, that $some_calculated_value is a property, handled by someCalculatedValue() method of generic. For now there is no way to declare that "method provides a property to class".