Improve Typecasting about ideas

[sebastiandedeyne]

Been pondering about the idea of casting to custom objects myself. Rough idea: classes that implement an interface with some sort of serialize & unserialize method, the class name could then be passed in the casts array.

interface DatabaseCastThing
{
    public function fromDatabase();
    public function toDatabase();
}

class Email implements DatabaseCastThing
{
    // ...
}

protected $casts = ['email' => Email::class];

[AdenFraser]

Well for starters, if you use accessors and mutators the result is an awful lot of code duplication.

If you have a Model with 10 castable values, that's 10 accessors and mutuators you'd have to setup, chances are this would be across multiple models. The only way I can see you'd avoid that is either through an abstract model (assuming each model shares similar values) or through a castable trait.

The other problem with accessors & mutators (and even the existing casting) is that nullable values required additional logic which again adds code duplication.

Imagine reproducing this:

    public function getOriginalPriceAttribute($value) 
    {
        if (is_null($value)) {
            return $value;
        }

        return new Money($value);
    }


    public function setOriginalPriceAttribute($value)
    {
        if (is_null($value)) {
            $this->attributes['money'] = $value;
        }

        $this->attributes['money'] = $value->toDecimal(); // or automatically to string via __toString(); etc.
    }

^That's an awful lot of code for what is essentially some incredibly simple typecasting.

Neither of these is a terribly elegant solution, compared to that of @sebastiandedeyne's idea above. Even there the toDatabase() method shouldn't be required in the interface... since an a value casted to an object with __toString(); would work just fine (assuming that is what the end-developer wants).

[martinbean]

I’m in the Accessors & Mutators camp for this.

[barryvdh]

Casts are usually one-way right? Just for getting the data from the database, with the exception of json/datetime, which are also converted back. So do you want to account for the 'back', case as well?

Also, isn't it easier to register custom casts, like the Validation? https://laravel.com/docs/5.2/validation#custom-validation-rules

TypeCaster::extend('money', function($attribute, $value, $parameters, $caster) {
    $currency = isset($parameters[0]) ? $parameters[0] : '$';
    return new Money($value, $currency);
});

TypeCaster::extend('html', 'App\Html@convert');

Usage like this:

 protected $casts = [
        'amount' => 'money:£'
    'html_string' => 'html',
    ];

If you want to convert back, perhaps we could consider a second (optional) callback.

TypeCaster::extend('money', function($attribute, $value, $parameters, $caster) {
    return Money::fromString($value);
}, function($attribute, $value, $parameters, $caster) {
    return Money::toString($value);
});

TypeCaster::extend('html', 'App\Html@encode', 'App\Html@decode');

Which would essentially be mutators I guess, but with easier configuration.

[barryvdh]

I don't get it either. If you're not sure about the architecture, discuss that privately before creating a PR.
If you're not ready for feedback, work on it locally before creating a PR.

If you do create a PR, accept feedback on it. These discussions are very valuable to read back later, to understand why something is done this way. Redirecting to Slack just means it's lost after a few days.

I really hope this isn't a trend.. IMHO locking should be reserved for out of control threads with just spam, not reasonable discussions..

[sebastiandedeyne]

What if we'd have the caster mutate the model instead of returning a serialized value? Another example implementation, similar to @barryvdh's:

class MyModel extends Model
{
    protected $casts = [
        'price' => 'money',
    ];
}

class CastsMoney
{
    public function get(Model $model)
    {
        return new Money($model->price_amount, $model->price_currency);
    }
    
    public function set(Model $model, Money $value)
    {
        $model->price_amount = $value->getAmount();
        $model->price_currency = $value->getCurrency();
    }
}

Casts::extend('price', CastsMoney::class);

Advanced: You could pass values as parameters, for example the field names, or a hard coded currency like in the previous example.

class MyModel extends Model
{
    protected $casts = [
        'total' => 'money:total_amount,total_currency',
        'shipping_costs' => 'money:shipping_costs_amount,shipping_costs_currency',
    ];
}

class CastsMoney
{
    public function get(Model $model, $amountField, $currencyField)
    {
        return new Money($model->$amountField, $model->$currencyField);
    }
    
    public function set(Model $model, Money $value, $amountField, $currencyField)
    {
        $model->$amountField = $value->getAmount();
        $model->$currencyField = $value->getCurrency();
    }
}

Casts::extend('price', CastsMoney::class);

I think this would cover everything we want:

• Define reusable custom accessors and mutators in $casts
• Getters and setters
• Create value objects from multiple fields

[AdenFraser]

Going to start putting some code together today and will put a PR together as a WIP

[robclancy]

Wow I see now. Because you're a disrespectful little snowflake.

…

On Sun, 26 Feb 2017, 03:29 Till Krüss ***@***.***> wrote: Valueless, off-topic comments like that. That why it's locked. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0UF0gCSZKB74uKD86eBioIezi3cIPTks5rgGTpgaJpZM4Hwgiw> .

[sisve]

Can someone explain why this issue is so secretive that I need to talk to @tillkruss in a hidden thread in #internals on Slack instead of commenting in the PR?

Additional things I've told @tillkruss in previously mentioned secretive thread;

1. The intermediate casting object (hereby known as ConverterThingie) should have an interface, and all methods should be instance methods.
2. The ConverterThingie should be instantiated using the container so it can have dependencies.
3. The current implementation will not ask the ConverterThingie about null values. This sounds wrong, the ConverterThingie's sole purpose in life is to convert things, it should be asked how to convert null values.

[robclancy]

Not sure why anyone would ever be against this. I actually expected it to just allow a custom type when I first used casting. It's just something one would naturally expect it to support and would be very easy to do so.

[lagbox]

Can we please stop this secretive nonsense. The point of this repository is so that [expletive deleted] isn't just on slack which disappears. This creates paper trails so other people can actually see the conversations and IDK maybe not waste their [expletive deleted] time on things that have already been discussed that they couldn't possibly [expletive deleted] know because they weren't on slack. There has to be somewhere this information lives that is accessible.
How many times does this obvious issue have to be pointed out?

@barryvdh agreed pre-emptive heavy-handed moderating is not good

[robclancy]

I mean... his first PR showed he doesn't care what other people think. Instead of closing he will just ignore everyone because he is better than them (unless one of the Laravel "inner circle twitter gods").

[taylorotwell]

Agree could be cool!

[AdenFraser]

But you have made attribute mutators which can readily be reused, on multiple models and multiple attributes without the duplicate code bloat required by using mutators.

[franzliedke]

Well, I don't agree with your tone.

[valorin]

Is there a reason you don't want to use Accessors & Mutators for this purpose?

I haven't seen any of the other discussions, so I don't know if it's been brought up before... but it's worth explaining why here, if it has.

[alexbilbie]

Casting to and from a JSON blob would be useful too

[arcanedev-maroc]

How about dynamic casting (like polymorphism) ? can be also sorted in a custom db column (castables).

[valorin]

Thanks for the detailed answer @AdenFraser - that's definitely a valid use case, would simplify a lot of repeated code for common things (common value objects come to mind!). Accessors and Mutators are great for simple one-off stuff, but it'd be nice to have the power of a class too without a lot of scaffolding. :-)

Casting to and from a JSON blob would be useful too
@alexbilbie I thought you could already do this using object or array?

[AdenFraser]

@taylorotwell What are your thoughts in regards to this? Obviously there are quite a few thumbs ups above aswell but having your go ahead before spending some time on a PR would be great!

[themsaid]

@AdenFraser I think you need to make the PR man :) the idea is quite interesting, now it's time to discuss implementation.

[AdenFraser]

Thrown together an early draft laravel/framework#13315

[robclancy]

Just do it like mutators in the model. You are overthinking this a lot. It
can be as simple as looking for a method called {castname}Cast. Or could
just be a single method where you can insert your own catings just like the
current ones work.

Models dont use a factory so doing it like the validator extending or blade
extending just wont work. It should be in object scope not class scope.

On Tue, 26 Apr 2016 22:37 Barry vd. Heuvel [email protected] wrote:

Casts are usually one-way right? Just for getting the data from the
database, with the exception of json/datetime, which are also converted
back. So do you want to account for the 'back', case as well?

Also, isn't it easier to register custom casts, like the Validation?
https://laravel.com/docs/5.2/validation#custom-validation-rules

TypeCaster::extend('money', function($attribute, $value, $parameters, $caster) { $currency = isset($parameters[0]) ? $parameters[0] : '$'; return new Money($value, $currency);});TypeCaster::extend('html', 'App\Html@convert');

Usage like this:

protected $casts = [
'amount' => 'money:£'
'html_string' => 'html',
];

If you want to convert back, perhaps we could consider a second callback.

TypeCaster::extend('money', function($attribute, $value, $parameters, $caster) { return Money::fromString($value);}, function($attribute, $value, $parameters, $caster) { return Money::toString($value);});TypeCaster::extend('html', 'App\Html@encode', 'App\Html@decode');

Which would essentially be mutators I guess, but with easier configuration.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#9 (comment)

[robclancy]

Also why would this need converting back?

On Wed, 27 Apr 2016 07:35 Robbo [email protected] wrote:

Just do it like mutators in the model. You are overthinking this a lot. It
can be as simple as looking for a method called {castname}Cast. Or could
just be a single method where you can insert your own catings just like the
current ones work.

Models dont use a factory so doing it like the validator extending or
blade extending just wont work. It should be in object scope not class
scope.

On Tue, 26 Apr 2016 22:37 Barry vd. Heuvel [email protected]
wrote:

Casts are usually one-way right? Just for getting the data from the
database, with the exception of json/datetime, which are also converted
back. So do you want to account for the 'back', case as well?

Also, isn't it easier to register custom casts, like the Validation?
https://laravel.com/docs/5.2/validation#custom-validation-rules

TypeCaster::extend('money', function($attribute, $value, $parameters, $caster) { $currency = isset($parameters[0]) ? $parameters[0] : '$'; return new Money($value, $currency);});TypeCaster::extend('html', 'App\Html@convert');

Usage like this:

protected $casts = [
'amount' => 'money:£'
'html_string' => 'html',
];

If you want to convert back, perhaps we could consider a second callback.

TypeCaster::extend('money', function($attribute, $value, $parameters, $caster) { return Money::fromString($value);}, function($attribute, $value, $parameters, $caster) { return Money::toString($value);});TypeCaster::extend('html', 'App\Html@encode', 'App\Html@decode');

Which would essentially be mutators I guess, but with easier
configuration.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#9 (comment)

[barryvdh]

If you cast it to an object and modify it, you want to return it to a value you can store in database, right?

[tomschlick]

Yeah I definitely think there should be a toDatabase method of some sort. By default it could just use __toString() but for more complicated implementations it would be useful to have, especially since __toString() is horrible for reporting errors.

[robclancy]

What, no? If you need to return it to the database you are using this
wrong. That is what mutators are for. Casting has a single use, to cast for
the JSON response. So for example JS doesn't do dumb things because you
accidently sent it your int in string form. If you need to cast something
and return it to the database at a later date that is the exact use case
for attribute mutators.

On Wed, Apr 27, 2016 at 7:47 AM Tom Schlick [email protected]
wrote:

Yeah I definitely think there should be a toDatabase method of some sort.
By default it could just use __toString() but for more complicated
implementations it would be useful to have, especially since __toString()
is horrible for reporting errors.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#9 (comment)

[tomschlick]

If you modify something in the cast object and then save the model it has to find its way back to the database. This is how the current casts system works. Try it with the carbon dates, it uses __toString() on the carbon instance.

[robclancy]

https://github.com/laravel/framework/blob/5.2/src/Illuminate/Database/Eloquent/Model.php#L2473

I don't see how that is modifying the model at all? It just casts for the attributes it is returning?

[tomschlick]

https://github.com/laravel/framework/blob/5.2/src/Illuminate/Database/Eloquent/Model.php#L2484

Shows how the dates are formatted with the serializeDate() method

[robclancy]

Yes, for the toArray method which then goes to a JSON response. It doesn't touch the underlying attributes? Casting an object returns the casted attributes, it doesn't change anything you can save like normal (unless I am missing something, and if I am I would say that is a bug).

[AdenFraser]

If you cast to datetime and simply use Carbon's ->addDay () method before
saving... the date stored in the database will be one day in the future
than it was before.

For instance

    $product->released_at->addDay ();
    $product->save ();

On the save action the Carbon instance is converted __toString in the
format the Eloquent date format is required in... with any modifications.

The same way if you modify a casted json array and subsequently save... it
gets updated. Or an array or any ither cast for that matter.
On 27 Apr 2016 00:16, "Robert Clancy (Robbo)" [email protected]
wrote:

Yes, for the toArray method which then goes to a JSON response. It
doesn't touch the underlying attributes? Casting an object returns the
casted attributes, it doesn't change anything you can save like normal
(unless I am missing something, and if I am I would say that is a bug).

On Wed, Apr 27, 2016 at 9:03 AM Tom Schlick [email protected]
wrote:

https://github.com/laravel/framework/blob/5.2/src/Illuminate/Database/Eloquent/Model.php#L2484

Shows how the dates are formatted with the serializeDate() method

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#9 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9 (comment)

[robclancy]

Then you are using casts wrong and shouldn't do that. Why would you ever cast something and then save it? Casting happens as the last thing to send a response. And even if you did need to save after casting it you have a cast method that changes the model attributes in some way that is a bug in your code because you are doing it wrong.

[robclancy]

The exact thing could happen with attribute mutators because it is simply not how you should do things.

[AdenFraser]

In the case of a Money cast, something like this could be very simple (and
relatively useless) use case:

    $invoice->balance->reduce (2.50):
    $invoice->due_date->addYear ();
    $invoice->save ();

The resulting row update for the model would perform the Money reduction
and the Date addition based on the casted objects __toString () return
value...
On 27 Apr 2016 00:21, "Aden Fraser" wrote:

If you cast to datetime and simply use Carbon's ->addDay () method before
saving... the date stored in the database will be one day in the future
than it was before.

For instance

    $product->released_at->addDay ();
    $product->save ();

On the save action the Carbon instance is converted __toString in the
format the Eloquent date format is required in... with any modifications.

The same way if you modify a casted json array and subsequently save... it
gets updated. Or an array or any ither cast for that matter.
On 27 Apr 2016 00:16, "Robert Clancy (Robbo)" [email protected]
wrote:

Yes, for the toArray method which then goes to a JSON response. It
doesn't touch the underlying attributes? Casting an object returns the
casted attributes, it doesn't change anything you can save like normal
(unless I am missing something, and if I am I would say that is a bug).

On Wed, Apr 27, 2016 at 9:03 AM Tom Schlick [email protected]
wrote:

https://github.com/laravel/framework/blob/5.2/src/Illuminate/Database/Eloquent/Model.php#L2484

Shows how the dates are formatted with the serializeDate() method

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#9 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9 (comment)

[robclancy]

What? You are making zero sense. What has that code got to do with casting at all?

[AdenFraser]

This is achievable using mutators, you are correct. But i don't understand how you can claim that casting can only be the last thing that happens before we send a response.

If that's the case then why is Eloquent casting dates to Carbon objects? Presumably based on what you are saying, just for response purposes, rather than for providing an API for manipulating dates.

[robclancy]

It doesn't even matter if it is last or not. Casting doesn't change the attributes at all. Eloquent casts to Carbon completely separate to casting. Casting has a single use, to cast attributes to their types for use in a JSON response. Casts are done when toArray is called and that is then JSON encoded.

[robclancy]

Dates are mutated: https://github.com/laravel/framework/blob/5.2/src/Illuminate/Database/Eloquent/Model.php#L2867

Casts have nothing to do with this. Casts ONLY return different types for the JSON response. They do not modify attributes in any way (unless you do it wrong after the proposed PR is merged).

[AdenFraser]

No it's not separate at all, try it out for yourself. Add a few extra columns, date, datetime, collection and cast them. Look at the Eloquent Model API:

 public function getAttributeValue($key)
    {
        $value = $this->getAttributeFromArray($key);

        // If the attribute has a get mutator, we will call that then return what
        // it returns as the value, which is useful for transforming values on
        // retrieval from the model to a form that is more useful for usage.
        if ($this->hasGetMutator($key)) {
            return $this->mutateAttribute($key, $value);
        }

        // If the attribute exists within the cast array, we will convert it to
        // an appropriate native PHP type dependant upon the associated value
        // given with the key in the pair. Dayle made this comment line up.
        if ($this->hasCast($key)) {
            $value = $this->castAttribute($key, $value);
        }

        // If the attribute is listed as a date, we will convert it to a DateTime
        // instance on retrieval, which makes it quite convenient to work with
        // date fields without having to create a mutator for each property.
        elseif (in_array($key, $this->getDates())) {
            if (! is_null($value)) {
                return $this->asDateTime($value);
            }
        }

        return $value;
    }

Clearly when you call for an attributes value, if a mutator doesn't exist the next operation is to check for a cast AND PERFORM CASTING if a cast exists.

[robclancy]

Then I stand corrected. And disagree with the casting working like that altogether. And also then disagree with custom casting doing more than just small things because of reversing being needed and when you add that you have just made attribute mutators.

[robclancy]

Then instead I think you should be adding the ability to do exactly as you just described. Not manipulating casts into a form of mutators that are a little more reusable. Just make current mutators reusable.

[AdenFraser]

@robclancy Now that is a new tanget of discussion entirely and one perhaps worth exploring. It all comes down to the expected functional difference between a cast and a mutator and making that clearly defined.

[robclancy]

Well the definitions are fairly clear. One is for casting types and one is mutating values. Once casts do more than change type they are mutating.

[robclancy]

This could be as simple as the base model having methods (or a trait) like usdGetMutator and usdSetMutator. Then a $mutate array working similar to the casts array.

But with better names for things.

[AdenFraser]

Sure. But if you are casting a monetary figure from a column into a monetery data type, then it's not exactly being mutated (because the underlying value hasn't immediately chnaged) it has just been cast to a different data type.

According to the eloquent docs:
The $casts property on your model provides a convenient method of converting attributes to common data types.

The supported cast types are: integer, real, float, double, string, boolean, object, array, collection, date, datetime, and timestamp.

[robclancy]

If that can easily save back then sure casts can work for that. And I still think we need to be able to do our own castings but it should be for very simple things. Anything more should be a mutator.

[robclancy]

Also if you clone the object before modifying it in the custom cast then this reverse issue goes away for the most part.

[AdenFraser]

Obviously it depends largely on use scenario. The docs suggest accessors and mutators for lowercase, uppercase, titlecase etc for first_name and I completely agree with that.

Casting to a Laravel Collection is provided as one of the cast types but I don't see any reason why an extended instance of a Collection shouldn't be castable too.

[AdenFraser]

I don't understand how the reverse issue is an issue. For instance if I store a json_encoded array of data in a column and I cast it to a collection, I want to be able to do things such as:

     $casts = [
         'casted_collection' => 'collection'
     ];

     $model->castedCollection->prepend('new first value')->push('new end value');
     $model->save();

And when the Eloquent Model is saved, the casted Collection is converted back to JSON, thanks to:

    /**
     * Convert the collection to its string representation.
     *
     * @return string
     */
    public function __toString()
    {
        return $this->toJson();
    }

And thus my revised values are stored in the database.

This is far simpler than having to define this combo in the model, no?

    public function getCastedCollectionAttribute($value)
    {
          return new Collection(json_decode($value));
    }

    public function setCastedCollectionAttribute($value)
    {
          $this->attributes['casted_collection'] = $value->toJson();
    }

[robclancy]

That is a very weak way of attribute mutating restricted to just __toString().

[AdenFraser]

It's late and I don't quite follow, so I'll let someone chime in and await some feedback on the WIP PR.

But as far as I'm aware this can prove to be a useful piece of additional functionality and I'm sure others agree but I'll wait for some other voices to confirm one way or another.

[JosephSilber]

I for one agree with Aden: casts should definitely work both ways.

[robclancy]

Then they should just be more "global" mutators.

[tomschlick]

On another note, the approach by @barryvdh was very nice. I would only suggest one thing, if only one param is submitted it should just be the class name and we would assume there is a toDatabase() / fromDatabase() or some default method on the class from the interface.

TypeCaster::extend('html', App\Html::class);

[tomschlick]

That allows you to do the class imports and leaves less room for error as its no longer in a string.

[michaeldyrynda]

Mutating should go both ways, but I'd be inclined to leverage __toString in most (all?) cases, given you're going to be putting text representations of your data into the database most of the time, right? Even a binary field is a textual representation of that content.

Or is the intention to store the serialized object wholesale into the database and unserialize it? In @AdenFraser's earlier example, he's using a mutator (setOriginalPriceAttribute) to explicitly call a method on the Money value object. Would it not make sense to just leverage __toString? Then again, you still have issues in dealing with null.

[tomschlick]

Using __toString() also removes your ability to debug if there are errors. Instead of the normal stack trace, you'll get "__toString() must not throw an exception" and it mutes the actual exception from the error.

[barryvdh]

The money object could be a formatted amount as strong, but perhaps you would want to store the integer value in the database. Or you could store an uuid as 16 bytes, but still want the 36 string version displayed as string in the front end.

What this could also achieve perhaps, is using the casts for the where* clause. En ->where('amount', $moneyObject), same as the datetime conversions.

And yes, custom casts would be very similar to mutators, only easier to reuse.

[tomschlick]

FYI, a new PR has been opened by @tillkruss to further the work that was started on this.

laravel/framework#18106

For now discussion it is locked as it is a work in progress.

[tillkruss]

That was actually a typo, hence the [WIP] in the title. I fixed it earlier today.

$user->token = 'larav3l-secr3t'; // does not work
$user->save();

[robclancy]

Why is it locked?

…

On Sun, 26 Feb 2017, 02:44 Till Krüss ***@***.***> wrote: That was actually a typo. I fixed it earlier today. $user->token = 'larav3l-secr3t'; // does not work$user->save(); — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0UF6oGUaBwLgBW07q_p-viPbLcmp9rks5rgFpogaJpZM4Hwgiw> .

[tillkruss]

Because I don't want people to comment, yet. If you have valuable feedback, ping me in Slack.

[robclancy]

What a bizzare thing to do. Just don't PR until ready...

…

On Sun, 26 Feb 2017, 02:47 Till Krüss ***@***.***> wrote: Because I don't want people to comment, yet. If you have valuable feedback, ping me in Slack. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0UFyBtqnOluRkwBPU8Cdcy5nKqb9jVks5rgFsrgaJpZM4Hwgiw> .

[tillkruss]

Valueless, off-topic, thread-hijacking comments like that. That why it's locked.

[franzliedke]

Ignoring Robbo's comments for a while, I too agree that it would be helpful to allow feedback directly on the PR, especially since it is work in progress. ;)

[robclancy]

That's actually agreeing with my comments. It's the entire point of a pull request. Locking it is just disrespectful to anyone following this feature request. It is saying to every one of them that they aren't good enough to comment on the super amazing PR. Regardless they will just discuss here anyway. So not only is the reason for the lock stupid but it is ineffective.

…

On Sun, 26 Feb 2017, 04:09 Franz Liedke ***@***.***> wrote: Ignoring Robbo's comments for a while, I too agree that it would be helpful to allow feedback directly on the PR, *especially* since it is work in progress. ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0UF-yihFvHihrdcUCDacZW4DvPkUgpks5rgG5pgaJpZM4Hwgiw> .

[robclancy]

Yeah because his tone was so welcoming. He was hostile first and the reason for "valueless" discourse in the first place. Ironic really.

[sisve]

The current implementation in laravel/framework#18106 has a large flaw; it requires ownership of the objects you cast to. That is often not the case; an example are people using https://github.com/nicolopignatelli/valueobjects which would require an intermediate casting layer. Something like a TokenConverter that has a convertToPHPValue($value) and convertToDatabaseValue($value)

[tillkruss]

Unlocked the thread and closed the PR. Will open new PR when it's ready.

[sisve]

For those that missed it; a new PR was opened.

Every single point I made was ignored.

1. There is no "casting object" that can declare constructor dependencies needed for conversion.
2. No interfaces for this new functionality to conform to, instead it's specially named methods that need to implemented in every model.
3. Null values are still ignored by the casting layer.

A quick reminder from that hidden-in-history Slack thread.

Did any of that happen?

[sisve]

It's way early in the morning and I misread the PR. It's not yet merged, and I updated my previous comment to remove that part.

I know I am bitter and filled of hatred, but could there at least be some notes about the different suggested implementations that show why those were declined? It's almost a year since the most thumbed-up (which I think means some kind of approval) comment suggested a way to do this, why wasn't that implemented? #9 (comment)