Wouldn't it be better to just have a default block in that switch statement that calls castTo{type}?

Currently if it's null, it bypasses object mapping altogether. In the use case I provided, I'd still want to get an instance of Settings when it's null so that the object can decide what to do.

I think the ability to extend castAttribute with custom cast types would be very helpful, and perhaps a better route to acheive the functionality you are after and offer greater flexibility for others?

If a check was made for a custom attribute cast type before both the check of a null value and the getCastType switch, it would be possible to create custom cast types for objects (including null objects), serialzed objects (which are not currenty supported) and any other implementations (binary, CSV, bson etc.)

👎

This involves using the application object that eloquent shouldn't know about.

Yeah, we probably won't be able to have access to the container from within Eloquent.

Probably the only option I can think of is to simply pass the raw database value into the object just using like new Settings($rawValue). And you can do whatever you want in the Settings constructor.

One thing I'm wondering about is how do you cast back for storage... like if I do:

$model = Model::find(1);
$model->settings = new Settings('something');
$model->save();

How do I know what to make settings in the database?

I appreciate the feedback. I did miss this in the implementation, but my thought was that casted objects would need to implement Jsonable. I see the challenges with the IOC container... maybe this functionality is best staying in a Laravel package.