Conversation
|
@schwern raised the potential issue that detecting Type::Tiny types saved in scalars might be problematic, in the method ignatures. However I don't think we should provide scalar types. Users should use provided Types::* types collections, or build their own additional types and add them to their own collections, and load them in M::Signature. So we never have types saved in scalars. |
|
It might be interesting to see how Physics-UEMColumn (which currently uses Method-Signatures, Moose and MooseX-Types) and Net-OAuth-LP (which currently uses Method-Signatures, Moo and Type-Tiny) behave with a Type-Tiny-based Method-Signatures. |
Those are excellent suggestions. They could be guinea pigs to see if this whole crazy idea works or not. :-) |
|
@tobyink I tried to use your patch but it doesn't work well in case of a Role or Class which has not yet been loaded at the time we call the ->_make_constraint. So I tried to defer this call and test for the presence of inline code when the string code is eval'ed, but I failed. I'll have to come back to this, probably after having pushed a M::S version with Type::Tiny only. |
This is my attempt to have Type::Tiny support. It includes test and doc
You should probably review the API, especially the new parameters to use M::S I've added, you'll probably want to reword/change it.
This work allows users to choose which type library to choose (for now any_moose or type_tiny, and which additional types collections to add (by default Types::Standard is added)
Becase Type::Tiny allows to get rid of Mouse/Moose, I plan to work on removing the hard requirement on Mouse and Any::Moose, to Moo and MooX::late. Any::Moose says in its doc anyway: "Any::Moose - deprecated - use Moo instead!"