Closed khrt closed 5 years ago
There needs to be a small patch to make coerce
work with Moose types. I'm going to submit a PR that builds on this one.
Related to @slobo's comment, I'm somewhat ambivalent about defaulting coerce
to 1. In Moose, you have to explicitly say coerce => 1
if you want your attributes to use coercion. I am guessing there was a good reason this was done, but I don't know what that reason was :).
PR #56 makes coerce
work for Moose types (with test). Thanks so much for implementing this!
My reasoning would be as follows:
In case of Moose
, attributes are generaly coming from other Perl code, so by the principle of least surprise I can see how it makes sense that it does not coerce by default, and instead just runs a type check. It did surprise me a bit that coercion doesn't happen by default, but I can see why you would want to be explicit about it there.
For Raisin
, data is coming over the wire and has no chance to be anything but basic Str
/Int
/HashRef
/ArrayRef
. If I'm already specifying some complex type
for the param, I can't currently think of a reason why I would want to be left with say bare HashRef
such that I have to instantiate the object myself†. Raisin already has the job of interpreting the HTTP::Request
and pulling parameters out of it - data is just bytes at that point, so perhaps there is no reason to default it to doing only "half" the job?
† A good next step may be for Raisin to introspect Moose types and add the attribute constraints and documentation to swagger. In this case I can see using coerce => 0
as being useful if I'd like documentation to be generated, but still want to do some manual checks on the data before it turns into a real object. But that would still be exception rather than the rule in my code style. YMMV :)
I would go with coerce
set to true
by default, with ability to disable it.
I've updated the Moose patch to resolve the conflicts (and use coerce by default).
Would
coerce => 1
be a good default? Seems to me that when specifying thetype
, it would be intuitive that Raisin would do it's best to instantiate an object of that type without needing to ask it viacoerce => 1
Ex, if I have this:
I would expect
$params->{period_start}
to be aDateTime
object.Or would it break things in the wild? Sorry if I'm confusing the issue.
Thanks