Skip Menu |

This queue is for tickets about the Type-Tiny CPAN distribution.

Report information
The Basics
Id: 88452
Status: resolved
Priority: 0/
Queue: Type-Tiny

People
Owner: perl [...] toby.ink
Requestors: djerius [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Coercion Hierarchies
I've defined the following (test code is attached) class_type Vector, { class => 'Vector' }; declare VecArray, as Tuple [ ( Num ) x 4 ]; coerce VecArray, from Tuple [ ( Num ) x 3 ], via { [ @{$_}, 1 ] }; coerce Vector, from VecArray, via { Vector->new( $_ ); }; These work: # coerce Tuple[ (Num) x 3] to VecArray validate( [ [1,2,3] ], VecArray ); # coerce Tuple[ (Num) x 4] (VecArray) to Vector validate( [ [1,2,3,1] ], Vector ); But this doesn't: # coerce Tuple[ (Num) x 3] to VecArray to Vector validate( [ [1,2,3] ], Vector ); It fails the find the first coercion. Is there a limit to how deep Type::Tiny looks for coercions? Thanks, Diab
Subject: ttype
Download ttype
application/octet-stream 1k

Message body not shown because it is not plain text.

On 2013-09-06T00:09:56+01:00, DJERIUS wrote: Show quoted text
> coerce Vector, > from VecArray, via { > Vector->new( $_ ); > };
In short: it doesn't look deeply at all. If you want to coerce Vector from from Tuple[Num,Num,Num], then you need to add that coercion to Vector itself. If you wish to avoid repetition, you could do something like this: coerce Vector, from VecArray->coercion->_source_type_union, via { Vector->new( to_VecArray($_) ); }; "from VecArray->coercion->_source_type_union" basically means "from anything that can be coerced to VecArray". I'm pretty sure that Moose type constraints act the same here, but I could be wrong. I'm unlikely to change this, firstly because I value compatibility with Moose type constraints and coercions; secondly because it would make it really easy to accidentally write recursive coercions. However, I could make the VecArray->coercion->_source_type_union solution a little prettier, along the lines of: coerce Vector, from VecArray->coercibles, via { Vector->new( to_VecArray($_) ); };
PS: Assuming I add a `coercibles` method, do you mind if I use your example here to document it?
On Fri Sep 06 05:43:19 2013, TOBYINK wrote: Show quoted text
> On 2013-09-06T00:09:56+01:00, DJERIUS wrote:
> > coerce Vector, > > from VecArray, via { > > Vector->new( $_ ); > > };
> > In short: it doesn't look deeply at all. If you want to coerce Vector > from from Tuple[Num,Num,Num], then you need to add that coercion to > Vector itself. > > If you wish to avoid repetition, you could do something like this: > > coerce Vector, > from VecArray->coercion->_source_type_union, via { > Vector->new( to_VecArray($_) ); > }; > > "from VecArray->coercion->_source_type_union" basically means "from > anything that can be coerced to VecArray". > > I'm pretty sure that Moose type constraints act the same here, but I > could be wrong. > > I'm unlikely to change this, firstly because I value compatibility > with Moose type constraints and coercions; secondly because it would > make it really easy to accidentally write recursive coercions.
True enough. I'd probably be the first in line to do that. Show quoted text
> However, I could make the VecArray->coercion->_source_type_union > solution a little prettier, along the lines of: > > coerce Vector, > from VecArray->coercibles, via { > Vector->new( to_VecArray($_) ); > };
That's much prettier (and safer, as _source_type_union isn't part of the public API).
On Fri Sep 06 05:50:51 2013, TOBYINK wrote: Show quoted text
> PS: Assuming I add a `coercibles` method, do you mind if I use your > example here to document it?
Not at all. Go right ahead. Diab
On Fri Sep 06 05:43:19 2013, TOBYINK wrote: Show quoted text
> > I'm pretty sure that Moose type constraints act the same here, but I > could be wrong.
From Moose::Manual::Types Moose does not attempt to chain coercions, so it will not coerce a single hex number. To do that, we need to define a separate coercion: So it looks like Type::Tiny's behavior is consistent. Might I suggest similar language in the docs? Thanks again, Diab
Show quoted text
> So it looks like Type::Tiny's behavior is consistent. Might I suggest > similar language in the docs?
Will do. The major difference between Type::Tiny's coercions and Moose's are that things like ArrayRef, HashRef, Dict, Map and Tuple all coerce deeply if their parameter has a coercion.
OK, there's an implementation in 0.027_01; still need to work on the docs.
On Sat Sep 07 18:00:35 2013, TOBYINK wrote: Show quoted text
> OK, there's an implementation in 0.027_01; still need to work on the docs.
Really stellar documentation in 0.027_04. Quite nice.
Fixed in 0.028.