support Type::Tiny

[dams]

It's all in the title... Type::Tiny is great, fast, light, minimalist, and works well with Moo. Can it be supported by M::S ? thanks

[barefootcoder]

Well, trying to find a way to support Moo is definitely on my list. I was looking at MooX::Types::MooseLike (somewhat doubtfully), but perhaps this is another alternative. I won't have any time until after YAPC, but I'll look into this first chance I get.

Thx for the tip!

[schwern]

Once #34 is done, Type::Tiny can definitely be added to the set of introspected type systems. However, allowing lexical scalars as types may cause type signature parsing to become ambiguous. That'll have to be thought through some.

my $NUM = "Type::Tiny"->new(
   name       => "Number",
   constraint => sub { looks_like_number($_) },
   message    => sub { "$_ ain't a number" },
);

method add( $NUM $left, $NUM $right ) {
    ...
}

[dams]

Didn't have more than 2 hours to spend... However, this simple hack makes the standard types supported:
dams@d1eb0e3
As this test demonstrates it:
dams@20a5367
Not sure how you guys want Type::Tiny types to be enabled. An option on M::S import ? or should Type::Tiny be checked before Any::Moose ? Also, I'll try to make class/rolle based types work. About custom types, I think that it's just a matter of the user adding it to the Type::Tiny registry that we would have built for M::S, so an ad-hoc method to do just that should be enough (so no need to parse custom types as scalar in the method signature). Any hint, help or guidance welcome.

[dams]

Please see Pull Request #83. It's probably better to continue discussion over there and close this bug.

[barefootcoder]

Well, I've finally found the time to review Type::Tiny, and I must say: it seems to me like it might be worthwhile to consider just using Type::Tiny for everything. I can't see anything that Moose can do that Type::Tiny can't, including some things that Mouse can't do. It's small, it's fast, it would basically moot #34, it works with Moose, Mouse, and Moo ... where's the downside to switching over to it for everything?

AFA this:

my $NUM = "Type::Tiny"->new(

goes, that's an anonymous type, and I don't see any reason to allow those in method signatures.

[rjattrill]

We get Types::Standard available by default with this I assume.

On Thu, Jul 4, 2013 at 2:11 PM, Buddy Burden notifications@github.comwrote:

Well, I've finally found the time to review Type::Tiny, and I must say: it
seems to me like it might be worthwhile to consider just using Type::Tiny
for everything. I can't see anything that Moose can do that Type::Tiny
can't, including some things that Mouse can't do. It's small, it's fast, it
would basically moot #34#34,
it works with Moose, Mouse, and Moo ... where's the downside to
switching over to it for everything?

AFA this:

my $NUM = "Type::Tiny"->new(

goes, that's an anonymous type, and I don't see any reason to allow those
in method signatures.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/81#issuecomment-20458294
.

[dams]

@barefootcoder I agree, I also think that using Typ::Tiny everywhere is a great choice.
@rjattrill: in my PR yes you get types::standard by default, and you can also load additional types at "use" time.

[barefootcoder]

We get Types::Standard available by default with this I assume.

Well, my suggestion is that you get it by default, by not-default ... you just get it, period. I may try some benchmarks with the Moose type vs Type::Tiny, because I suspect that Type::Tiny will be faster, but I'll need to prove it. But, assuming Type::Tiny is faster, it appears to be just as featureful, you can create new types with it just as easily, it handles coercions just as well, and it works seamlessly with Moose (as well as all the others). So I'm having difficulty imagining why, as a user, you'd ever not want to use it.

I guess what I'm asking is, can anyone think of any reason why someone would prefer using Moose types over Type::Tiny?

Ah, here's one: what if you already have a bunch of Moose types built up--subtypes and enums and whatnot. You have your own type registry going, and you don't want to switch to Type::Tiny (why not, other than just not having the time to do it, I can't imagine, but that's not for us to say). Can Type::Tiny handle user-defined types, if those types are defined via Moose?

[dams]

In my opinion, M::S should be flexible enough to be used with Moose types or Types::Tiny, and maybe others.

As you said, some people may want to prefer Moose types because they work on existing code that uses it and they cannot migrate, or they use specific features of Moose types (if any).

However, one big advantage of Type::Tiny is the fact that you can have more than one Type::Registry, instead of the global namespace for Moose types, which forces you to heavily namespace your types.

Also, what about backward compatibility ? it would be a shame that a new version of M::S breaks your code and forces you to migrate to Type::Tiny

Last but not least, what if other types implementation emerge ? we've seen Moose, Mouse, then Moo (I won't mention the other Mo* stuff...) And it's difficult to see in advance which one are going to be used ultimately.

So if there can be a clever way to be compatible with any type implementation, I'm all for it.

[barefootcoder]

@dams: Let me take your points one at a time:

... some people may want to prefer Moose types because they work on existing code that uses it ...

Using Moose types for your attributes and Type::Tiny for your method parameter types should present no problems as long there aren't any differences (even subtle ones) between the two implementations for the same type, which I don't believe there are.

... or they use specific features of Moose types (if any).

But that's what I'm saying: I believe that the way @tobyink has designed Type::Tiny is that it both is and always will be feature-compatible with Moose types.

Also, what about backward compatibility ?

Given feature compatibility, I can't see any way that this change would break backcompat.

Last but not least, what if other types implementation emerge ? we've seen Moose, Mouse, then Moo (I won't mention the other Mo* stuff...)

Well, exactly. Type::Tiny is a way to get off this demonic merry-go-round. If we say, "we don't care what crazy system you're using, and whatever types it wants to use, we're going to use Type::Tiny" then we don't give a crap what the next type craze is.

Now, I'm making some assumptions here (faster implementation, full feature compatibility, commitment to maintain such, etc). I'm going to have to do some investigation to verify these things. I could be wrong, and, if I am, then the question is moot and we'll have no other choice than to support multiple implementations. But, if I'm right ...

Why not?

[tobyink]

Here's a few random points...

1. If you've got a MooseX::Types type constraint, you can convert it to Type::Tiny using Types::TypeTiny::to_TypeTiny( SomeMooseXTypesType ).
2. The above is automatically done by Type::Tiny all over the place. So if ArrayRef is a Type::Tiny type, and Foo is a MooseX::Types type, then ArrayRef[Foo] ought to "just work".
3. With regards to speed, most of my benchmarking has used type constraints within Moo/Mouse/Moose attributes. Type::Tiny outperforms all of them except Mouse::XS. However I suspect that Method::Signatures doesn't get the full benefit of Mouse::XS's speed anyway, because it interacts with it on the Perl side rather than calling the C functions directly.
4. Type::Tiny is planned to track Moose/Mouse/Moo's API as closely as possible. Of course it may be that in the future they diverge so far that tracking them all becomes impossible.
5. "what if other types implementation emerge" - there is Specio which is a project with similar aims to Type::Tiny, but a different (somewhat saner) API. As of current versions, it cannot be dropped into Moo/Mouse/Moose and actually work - because Mouse/Moose want a type constraint object with an insane API - but with patches in future versions of the OO frameworks, they may offer support. (In which case, Type::Tiny's API will change to match Specio's, at least as far as required for point 4 above.)
6. Converting a string such as "ArrayRef[Int]" into a type constraint object is something that's fairly new in Type::Tiny. This is the Type::Registry stuff in dams' patch. The next version of Type::Tiny will hopefully offer a bit more DWIM here; for example, if you have a string like "Foo::Bar" and Foo::Bar doesn't correspond to a known type constraint, it will assume you meant "InstanceOf['Foo::Bar']".
7. There are one or two issues with dams' patch. In particular, calling "Type::Registry"->for_me from within Method::Signatures will always return the same Type::Registry object, so you lose the benefit of per-package type registries. You want "Type::Registry"->for_class($class_being_compiled). (Or better, the DWIM stuff in the next release.)
8. Don't add a dependency on MooX::late. The DWIM stuff in next release is basically a port of the DWIM stuff that's already in MooX::late.
9. It would be really nice to have a module offering method signatures using Type::Tiny. I'd use it. :-) Function::Parameters kind of supports Type::Tiny, but using a less nice syntax than it does for Moose types.
10. Any change should probably be preceded by a longish period of trial releases, as this may cause problems for people using Method::Signatures. But if I understand things correctly, with Data::Alias b0rked, you've probably got a longish period of trial releases coming up anyway.

[thoughtstream]

FWIW, I would be delighted if M::S could drop all it's Moose/Mouse
dependencies.

I have nothing against that worthy ecosystem, except that it makes using
M::S a
much heavier proposition and correspondingly less viable in certain types
of
development.

If Type::Tiny can reduce the M::S memory footprint, I'm all for it!

Damian

[barefootcoder]

@tobyink: Thanks for all the detailed explanations. I'm just waiting to hear from @schwern at this point to get his input. I may try to fiddle with the idea on a branch, as a proof of concept.

One question/clarification: You talk about the automatic translation of Moose types to Type::Tiny types. Let's say that a user creates one or more new Moose types, using subtype or enum or what-have-you. Will I be able to write the type checking for MS in such a way that, if these new types are used as parameter types in sigs, they'll just be automagically converted to appropriate Type::Tiny types? 'Cause, if that could work, then I really can't see any reason not to just go with Type::Tiny for everything here.

@thoughtstream:

I have nothing against that worthy ecosystem, except that it makes using M::S a much heavier proposition and correspondingly less viable in certain types of development.

Well, remember that MS doesn't depend on (or drag in) Moose, which is the heavy one. MS will never use Moose unless you use it first. Mouse is a much smaller dependency. Now, that having been said, here's what perlbloat tells me on 5.14.4:

Moose: 30.4Mb
Mouse: 7.7Mb
Type::Tiny: 2.9Mb

So, while Mouse is a hell of a lot better than Moose (and I don't think worthy of being considered a much heavier proposition), Type::Tiny is even better.

I continue to wait for @schwern, but I'm really feeling more and more like Type::Tiny is the way to go here. Can anyone offer any counterindication to my enthusiasm?

[dams]

@barefootcoder as per the @tobyink remarks, I now understand your approach. The major drawback for me was if a user has a ton of Moose types that he couldn't use in Type::Tiny. If that's transparently handled by T::T, then it's all good. And indeed we can consider T::T as the central compat layer for MOP implementations. But now, I'm tempted to try Specio types in Method::Signatures :)

@tobyink

About the Type::Registry issue: in my patch I always use the same type registry because I wanted all custom types to be available accross all code that uses M::S. A little bit like the global Moose type registry.

If I change the patch to do what you suggest, it means that every class using M::S with custom T::T types will have to load these custom types to their registry each time they use Method::Signatures. Am I right ?

Maybe the solution is to ask people to put their custom types in a single registry that they pass to Method::Signature at use time ? like use Method::Signature registry => $reg. Exposing the registry would be nicer than the load_types option I implemented. But then I'm worried about the syntax complexity.

About DWIM stuff: from my tests, I think this already works fine with my patch. If you look at type_check_type_tiny.t line 41 you'll see that I've commented the line just because the error message is different and the test fails. But it properly recognizes Foo::Bar as being InstanceOf['Foo::Bar']. Is it a strange side effect?

Anyway I'll wait for that DWIM release, and in the mean time try to improve my patch.

@barefootcoder: Shall I give it a new try with a new PR removing Mo*se altogether and relying only on TT ?

[tobyink]

Let's say that a user creates one or more new Moose types, using subtype or enum or what-have-you. Will I be able to write the type checking for MS in such a way that, if these new types are used as parameter types in sigs, they'll just be automagically converted to appropriate Type::Tiny types?

The following test script passes (except the TODO) in the latest dev release of Type-Tiny...

use strict;
use warnings;
use Test::More 0.96;
use Test::TypeTiny;

use Moose;
use Moose::Util::TypeConstraints qw(:all);
use Type::Utils 0.015 qw(dwim_type);

# Creating a type constraint with Moose
subtype "Two", as "Int", where { $_ eq 2 };

my $two  = dwim_type("Two");
my $twos = dwim_type("ArrayRef[Two]");

isa_ok($two, 'Type::Tiny', '$two');
isa_ok($twos, 'Type::Tiny', '$twos');

should_pass(2, $two);
should_fail(3, $two);
should_pass([2, 2, 2], $twos);
should_fail([2, 3, 2], $twos);

# Creating a type constraint with MooseX::Types
{
    package MyTypes;
    use MooseX::Types -declare => ["Three"];
    use MooseX::Types::Moose "Int";

    subtype Three, as Int, where { $_ eq 3 };
}

# Note that MooseX::Types namespace-prefixes its types.
my $three = dwim_type("MyTypes::Three");
my $threes = dwim_type("ArrayRef[MyTypes::Three]");

TODO: {
    local $TODO = 'this probably needs fixing';
    isa_ok($three, 'Type::Tiny', '$three');
}

isa_ok($threes, 'Type::Tiny', '$threes');

should_pass(3, $three);
should_fail(4, $three);
should_pass([3, 3, 3], $threes);
should_fail([3, 4, 3], $threes);

done_testing;

I wouldn't like to say that everything would be completely transparent. There are always going to be weird edge cases.