Hi, I have a very simple example like this:

class User extends Model
{
    use Fluent;

    public string $name;
}

Within tests:

$user = UserFactory::new()->create();
dd($user->name);

Throws an error:

Error : Typed property App\Models\User::$name must not be accessed before initialization

This PR add CarbonImmutablecast support, as it is natively supported by Laravel as immutable_datetime I think this PR is important for programmers like me as the packages is unusable to cast dates when using Date::use(CarbonImmutable::class); as all dates and datetimes will be instance of CarbonImmutable

Hi, i was testing some models with uuid, so i need to add de $incrementing property to false like the docs, that throws an error, i guess is for the public access of the property

class User extends Model
{
     use Fluent;

     /**
     * Indicates if the IDs are auto-incrementing.
     *
     * @var bool
     */
     public $incrementing = false;
}

when i try to retrieve the model from database this throw

    PHP Error:  Call to a member function getName() on null

by the way, i love this package

I was thinking it might be possible to mark properties as fillable or guarded for Laravel's mass-assignment protection.

class Person extends Model
{
    use Fluent;

    #[Fillable]
    public string $first_name;

    #[Fillable]
    public string $last_name;

    // not fillable since it does not have the Fillable attribute
    public bool $is_admin;
}

If you are not interested in adding this feature, no big deal.

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 9.x.

Before merging, you need to:

• Checkout the l9-compatibility branch
• Review all comments for additional changes
• Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

This is an idea of how to improve on Laravel's accessors so that you would get IDE autocompletion and other benefits of having it defined as a real property.

class Person extends Model
{
    use Fluent;

    public string $first_name;
    public string $last_name;

    #[Accessor('getFullNameAttribute')]
    public readonly string $full_name;

    #[Accessor(function() {
        return $this->first_name . ' ' . $this->last_name;
    })]
    public readonly string $full_name2;
}

The readonly keyword will not work until PHP 8.1 and also I do not think it is possible to pass a closure to an attribute until PHP 8.1. The first accessor lets you reference a method name and the second example defines the logic in the closure.

Feel free to close this issue if you are not interested in adding this feature.

Hello , I'm facing the following exception

Error : Call to a member function getName() on null
 /var/www/codebase/itrainer_dashboard/vendor/based/laravel-fluent/src/HasProperties.php:56

When i override Eloquent model public properties that doesn't have types like [ $timestamps ]

Simple Solution is to exclude public properties without types with the following

 ->reject(fn (ReflectionProperty $property) => $property->getType() === null)

Hello, I've recently stumbled across this library. I really like what it's aiming to do, so I wanted to submit some changes that I've been working on.

This supports both types of default values that are available:

1. Defining a default within the eloquent model's $attributes array, and
2. Setting a default value on a PHP property being managed by Fluent

Under the hood, the main gimmick to make this work is that any default values defined on PHP properties will be copied into the eloquent model's $attributes array. That allows Laravel's internals to truly see that value as a default value, in the event of e.g. creating a new, empty instance of a model.

We also override the setRawAttributes method to unset our managed properties in a way similar to how this code already behaved in setAttribute. Within our overridden setRawAttributes, we also want to avoid triggering redundant calls to parent::setAttribute, so there's a simple flag for doing that.

Resolves #10

Test cases included.

Now that Laravel implements a Illuminate\Support\Fluent class there is a risk of confusion when using the trait:

class User extends Model {
  use Fluent; // Here comes the confusion, are we using this package or Laravel's class?
}  

A simple workaround is to alias the class, eg:

use Based\Fluent\Fluent as HasFluentAttributes;

class User extends Model {
  use HasFluentAttributes;
}  

One could say there's a great risk to forget doing this when generating a model with artisan make:model.
Publishing then editing the stubs could be a workaround, but this would create a lot of friction for simpler projects.

I'd suggest renaming the trait so users don't risk any error.

Let me know if you're OK with that and I'll drop a PR.

Fantastic project!

Any chance we can get support for Custom Casts? https://laravel.com/docs/8.x/eloquent-mutators#custom-casts

If no one with experience with the project has time, I can try implementing the feature, but in that case some help (i.e. direction) would be needed.

I really like the possibilities for this library. What do you think about the idea of letting people add laravel validation constraints to fields as well. So when you setAttribute() something, it'll validate and throw exceptions when invalid data is set into the model.

Since it's optional and built when the class is constructed, it should be fairly transparent. Something like this might be nice

#[Validate('int|between:3,100')]
public int $someNumber;

Then if I set a valid of 200, it'll throw a validation exception that if I want to catch myself and handle, I can do so. Or perhaps add a default or fallback values for situations where it might be appropriate.