-
Notifications
You must be signed in to change notification settings - Fork 11.7k
[6.0] Give ability to cast from mutator #29584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
|
Unclear what this is used for. Code example? |
|
In the The problem is that I have to manually perform the I am proposing allowing to call If I used the By adding 3rd param to the Check the commit changes to see how this 3rd argument affects the mutator call. Example 1protected $casts = [
'field' => 'array',
];
public function setFieldAttribute($value){
// some validation
}Example 2protected $casts = [
'field' => 'array',
];
public function setFieldAttribute($value){
// some validation
$this->attributes['field'] = json_encode($value);
}Example 3protected $casts = [
'field' => 'array',
];
public function setFieldAttribute($value){
// some validation
$this->setAttribute('field', $value);
}Example 4protected $casts = [
'field' => 'array',
];
public function setFieldAttribute($value){
// some validation
$this->setAttribute('field', $value, true);
} |
|
There's an open PR that suggests similar functionality: #29424 |
|
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. |
|
Laravel tries to avoid boolean flags for parameters because they aren't particulary obvious what they do: |
|
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 ? |
|
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. |
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.