Skip to content

Conversation

@ed9
Copy link

@ed9 ed9 commented Aug 15, 2019

When in mutator, you want to cast array's or dates etc - why should you do this manually when you have a perfectly fine casting functionality that is not available due to "mutator" restriction.

When in mutator, you want to cast array's or dates etc - why should you do this manually when you have a perfectly fine casting functionality that is not available due to "mutator" restriction.
@driesvints driesvints changed the title Give ability to cast from mutator [6.0] Give ability to cast from mutator Aug 15, 2019
@taylorotwell
Copy link
Member

Unclear what this is used for. Code example?

@ed9
Copy link
Author

ed9 commented Aug 15, 2019

In the Example 1 I am forced to do as shown in Example 2.

The problem is that I have to manually perform the json_encode but I want to rely on the cast i have setup.

I am proposing allowing to call setAttribute that holds the casting ability to cancel out the mutator call.

If I used the Example 3 you would go in an endless loop due to mutator re-call.

By adding 3rd param to the setAttribute we allow exempt for this method whereby we ignore the mutator call - see Example 4.

Check the commit changes to see how this 3rd argument affects the mutator call.

Example 1

protected $casts = [
   'field' => 'array',
];

public function setFieldAttribute($value){
   // some validation
}

Example 2

protected $casts = [
   'field' => 'array',
];

public function setFieldAttribute($value){
   // some validation
   $this->attributes['field'] = json_encode($value);
}

Example 3

protected $casts = [
   'field' => 'array',
];

public function setFieldAttribute($value){
   // some validation
   $this->setAttribute('field', $value);
}

Example 4

protected $casts = [
   'field' => 'array',
];

public function setFieldAttribute($value){
   // some validation
   $this->setAttribute('field', $value, true);
}

@garygreen
Copy link
Contributor

There's an open PR that suggests similar functionality: #29424

@ed9
Copy link
Author

ed9 commented Aug 15, 2019

The #29424 is indeed similar and on the same topic, but the proposed is based on the return principle which not as readable as this format especially for new team members joining team and working on code they've not worked on.

Also the return format does not offer validation post casting, whereby I could call casting and then run validation - I decide when to cast and when to validate.

@garygreen
Copy link
Contributor

Laravel tries to avoid boolean flags for parameters because they aren't particulary obvious what they do: $this->setAttribute('field', $value, true) - it's not clear what the true value does.

@ed9
Copy link
Author

ed9 commented Aug 16, 2019

To counter the third argument, this setAttribute functionality could be split in two methods then? This way the ability to call cast from within the mutator or accessor becomes possible through a helper call, which is the main issue at hand.

‘setAttribute’ - call mutator helper, then call casting helper.

‘setFieldAttribute’ - do some validation, then cast through w helper, then more validation, then set against current format via ‘$this->attributes’

What’s your view on such approach then ?

@taylorotwell
Copy link
Member

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!

If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants