How is the reverse casting handled, when the values (the string) needs to be written back to the database (the binary array)?

Thanks @sisve - good point. I'll add that in to.

See @sisve's comment. Not fleshed out and is actually very complicated to do in a proper way IMO.

@therocis @taylorotwell maybe it should be done in a very similar style like we have custom validation rules in Laravel 5.5 already? In this case we would need to introduce Cast interface with fromDatabase and toDatabase methods.

This is on how the model could look like:

use App\Casts\MoneyCast;

class Order extends Model
{
    protected $casts = [
         'money' => new MoneyCast
    ];
}

This is on how the custom cast definition could look like:

use Illuminate\Database\Eloquent\Cast;

class MoneyCast implements Cast
{
    public function fromDatabase($value)
    {
         // should return casted value (string, object, etc..)
    }

    public function toDatabase($object)
    {
         // should reverse-transform value / object back to the string that needs to be stored in the database
    }
}

This would defintely introduce a lot of flexibility and re-use across different models too.

There has been some development/research into this area earlier; look into #18229 and if you want to continue on that approach.

@sisve @taylorotwell Another possible implementation that could work is having a CastingManager in the same way the Notification system has a ChannelManager.

Something like

Casting::driver('array') - each driver then having the above fromDatabase() and toDatabase() method.

This allows package developers to hook into the casting and extend with their own by Casting::extend('money', ...). All the existing eloquent casts could be extracted to drivers as well.

A lot of the previous discussions on this feature in #13706 has been around mutability and caching which divides people a lot. People then argue to just use getters and setters leaving the models to have 2*n functions with duplicated logic.
Keeping this feature to basically just be a wrapper around get-attribute and set-attribute might ease the divide.
Instead of having mutability as discussed in previous PR you'd just have to be explicit (which also works for immutable value objects in turn)

$product->price = $product->price->add(100, 'USD');

Finally the object itself are not aware of Eloquent which has been another pain point discussed. There are no more coupling to your model and 'risk' of referencing relations than what would otherwise have been going on in the getter and setter.

Wouldn't this be a treat for 5.6 ? :-)

For those that may be interested, I've developed https://github.com/hnhdigital-os/laravel-model-schema which provides the mechanism for custom attribute types.

The package does a bit more, such as grouping everything into a protected schema property and adding the ability to set per attribute, an auth checking method (per attribute, or a callable method to check). The way it's implemented, it continued to provide the properties that are expected.

I have 73% tested at time of writing and hope to get to 100% shortly (only L5.5, but will play with 5.6 shortly).

@rasmuscnielsen Your example was actually my first test of the custom type. I've implemented a Money\Money casting. I'll be implementing a JSON upgrade to do a similar thing.