[PHP 8.4] Usage of property hooks for true typesafety and autocomplete

[TimKunze96]

With the introduction of PHP 8.4 property hooks got added to the language. With that comes the opportunity to finally archive native type-safety and auto-complete, without the need to write any docblocks!

How does it work?

We just have to define a virtual property for each attribute that we want to be typed, like the example below.

<?php

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    public int $id {
        get => $this->getAttribute('id');
        set {
            $this->setAttribute('id', $value);
        }
    }

    public string $name {
        get => $this->getAttribute('name');
        set {
            $this->setAttribute('name', $value);
        }
    }

    public string $email {
        get => $this->getAttribute('email');
        set {
            $this->setAttribute('email', $value);
        }
    }

    public string $password {
        get => $this->getAttribute('password');
        set {
            $this->setAttribute('password', Hash::make($value));
        }
    }
}

Noticed the different syntax between the get- and set-methods? This is because the shorthand arrow function returns the value and sets it as the new property value. However setAttribute does not return just the value set itself, but a reference to the full object. This is why we use the expanded {} syntax to get around this issue.

We could create a new trait that allows us the clean this up a little bit:

<?php

trait HasProxyAttributes
{
    public function read(string $key): mixed
    {
        return $this->getAttribute($key);
    }

    public function write(string $key, mixed $value): mixed
    {
        $this->setAttribute($key, $value);
        return $value;
    }
}

This trait is just a simple wrapper around the get/setAttribute functions, with the key difference being that it returns the value that it sets. This allows us to use the shorthand syntax for both the getter and setter, like this:

<?php

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    use \App\Traits\HasProxyAttributes;

    public int $id {
        get => $this->read('id');
        set => $this->write('id', $value);
    }

    public string $name {
        get => $this->read('name');
        set => $this->write('name', $value);
    }

    public string $email {
        get => $this->read('email');
        set => $this->write('email', $value);
    }

    public string $password {
        get => $this->read('password');
        set => $this->write('password', Hash::make($value));
    }
}

The last change we can make here is to make use of the __PROPERTY__constant, so we don't have to write the property name over and over again:

<?php

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    use \App\Traits\HasProxyAttributes;

    public int $id {
        get => $this->read(__PROPERTY__);
        set => $this->write(__PROPERTY__, $value);
    }

    public string $name {
        get => $this->read(__PROPERTY__);
        set => $this->write(__PROPERTY__, $value);
    }

    public string $email {
        get => $this->read(__PROPERTY__);
        set => $this->write(__PROPERTY__, $value);
    }

    public string $password {
        get => $this->read(__PROPERTY__);
        set => $this->write(__PROPERTY__, Hash::make($value));
    }
}

And just like that we get truly typed attributes for all our models!

I tested this approach on a couple of codebases by now and found no conflicts so far. Please let me know if you spot any issues with this

[macropay-solutions]

Hi.
This does not solve the clashes between the active record properties and the columns. See #43716 (reply in thread). But laravel does not care about corner cases so it can be a good option (even now they are recommending to use set and get attribute for property-attribute clash).

But at least it handles the toArray() function, so it is a step forward. But you still have to define the properties in the $fillable property.

Also if you cast datetime to Carbon (just as an example), you would have to handle 2 types in the property definition.

This active record was not meant to be used as an Entity or DTO. Of course in a happy flow you can use it as you wrote above, but if you want bulletproof solution....

[macropay-solutions]

Also this code is duplicate

{
        get => $this->read(__PROPERTY__);
        set => $this->write(__PROPERTY__, $value);
    }

Would be nice if it could be extracted.

[TimKunze96]

Unfortunately there is no way to reduce this further as far as I know

[macropay-solutions]

Interesting to see how this would behave:

    public string | int $created_at {
        get => $this->read('created_at');
        set => $this->write('created_at', $value);
    }


$model->setAttribute('created_at', \now());

dd($model->created_at);

Bottom line is that casts will need special handling

[TimKunze96]

Yes, if the value is casted you'd have to define it as such:

public Carbon $created_at {
    get => $this->getAttribute($value),
    set { $this->setAttribute('created_at', $value)}
}

[macropay-solutions]

If casts to array are used: https://wiki.php.net/rfc/property-hooks#arrays
So this is another corner case that is not handled (yet).

[macropay-solutions]

@TimKunze96 if you couple your solution with ours, you would cover also the clashes at the expence of more code/text being needed: #43716 (reply in thread)

<?php

namespace App\Models\Attributes;

use MacropaySolutions\LaravelCrudWizard\Models\Attributes\BaseModelAttributes;

///**
// * @property int $id
// * @property string $name
// * @property string $email
// * @property string $password
// * @property string $created_at
// * @property string|null $updated_at
// */
class ExampleModelAttributes extends BaseModelAttributes
{
    public int $id {
        get => $this->read('id');
        set => $this->write('id', $value);
    }

    public string $name {
        get => $this->read('name');
        set => $this->write('name', $value);
    }

    public string $email {
        get => $this->read('email');
        set => $this->write('email', $value);
    }

    public string $password {
        get => $this->read('password');
        set => $this->write('password', Hash::make($value));
    }

    public string $created_at {
        get => $this->read('created_at');
        set => $this->write('created_at', $value);
    }

    public ?string $updated_at {
        get => $this->read('updated_at');
        set => $this->write('updated_at', $value);
    }

// The bellow 2 functions can be moved into the parent class for DRY.
    protected function read(string $key): mixed
    {
        return $this->ownerBaseModel->getAttribute($key);
    }

    protected function write(string $key, mixed $value): mixed
    {
        $this->ownerBaseModel->setAttribute($key, $value);
        return $value;
    }
}

In the above the dock-block can be removed and replaced with your solution from the class' body.

<?php

namespace App\Models;

use App\Models\Attributes\ExampleModelAttributes;
use MacropaySolutions\LaravelCrudWizard\Models\BaseModel;

/**
 * @property ExampleModelAttributes $a
 * @mixin ExampleModelAttributes
 */
class ExampleModel extends BaseModel
{
    /**
     * @inheritdoc
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * @inheritdoc
     */
    protected $hidden = [
        'password',
    ];
}

You would use it like:

$model->a->id;

[macropay-solutions]

This could introduce multiple places for altering the value

        set => $this->write(__PROPERTY__, Hash::make($value));

because you can also do it in a function password() or via the old settler setPasswordAttrribute($value)

[macropay-solutions]

@TimKunze96 your solution will return null for unset properties (edit "NOT CODED properties") and will not behave like a normal php class would.

If you want it to behave like a php class, we implemented it: #55188 (reply in thread)

[TimKunze96]

Hm it will only return null if the type declaration allows for it, otherwise it will throw an error. How is that behavior different?

   // Throws error if 'read' returns null, because property is not nullable
    public string $name {
        get => $this->read('name');
        set => $this->write('name', $value);
    }

   // Does not throw error if 'read' returns null, because property is nullable
    public ?string $name {
        get => $this->read('name');
        set => $this->write('name', $value);
    }

[macropay-solutions]

You are right. It covers also this part. Our mistake. We meant to say that if you use an undeclared property (dynamic) it will return null.

(new Model())->column_that_does_not_exist