Coerce value prior validation (fixes #32)

[slobo]

Would coerce => 1 be a good default? Seems to me that when specifying the type, it would be intuitive that Raisin would do it's best to instantiate an object of that type without needing to ask it via coerce => 1

Ex, if I have this:

params(
  requires( period_start => ( type => 'DateTime' ) )
);
get fun($params) { ... }

I would expect $params->{period_start} to be a DateTime object.

Or would it break things in the wild? Sorry if I'm confusing the issue.

Thanks

[mschout]

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.

[mschout]

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 :).

[mschout]

PR #56 makes coerce work for Moose types (with test). Thanks so much for implementing this!

[slobo]

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 :)

[khrt]

I would go with coerce set to true by default, with ability to disable it.

[mschout]

I've updated the Moose patch to resolve the conflicts (and use coerce by default).