You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #370. This wouldn't be an issue if we stopped creating initializers behind the scenes. Also for whatever its worth, I don't think Granite ever worked like that, as the old cast_to_field method was setting the ivars directly as well.
Yeah, I agree. We should treat params as a serializer, similar to json, yaml, or xml. In Amber, we could initialize the object using Class.from_params method.
Question: should serializers call the setter method?
Or treat it more like DB::ResultSet and overload #new for HTTP::Params or something like that.
It would be doable to make it configurable. The serializer we use at work (in PHP) allows you to control the access method; whether it should use reflection or public methods. We could do something similar as I can see the pros and cons of each approach.
When calling
new
with a list of params, it should call the setters for a column so you can override the default behavior.The text was updated successfully, but these errors were encountered: