[Perl5-syntax] Adding Moose type checking to Method::Signatures

[Buddy Burden]

Michael,

> Long story short:  I'll happily accept patches so Method::Signatures can parse
> Perl 6 types.

Excellent!  That's perhaps more effort that I was originally going to
put into it, admittedly, but I can probably sneak it into the time
they're giving me at $work.

>  What's done with that information is open to discussion, but it
> sounds like once MS has done the parsing you've figured out how to add your
> type check.

Yeah, I went through MXMS and tried to examine exactly what it was
doing, and I only see 3 things it's verifying that MS doesn't already
handle:

*) type
*) "does"
*) type coercions

I was just going to live without the latter two.  But, if I'm going to
end up modifying the parsing, I could possibly add those too ... or at
least some sort of hooks for them.

> Something you should know: the MS code was written in the manner of a
> prototype in that it's a bit of a mess and not very extensible and it was just
> about getting it to work.

It's actually not very messy at all.  In fact, out of all the code I
pored through yesterday, I'd say it was the easiest to follow.
Extensible, though ... yeah, it might need some help in that
department. ;->

> I've been meaning to rewrite it into something
> extensible.  Something with better separation between the signature parser and
> the code generator.  If you want to take that on, we can talk about that.

Well, I'll at least consider it.  I'm embarking on a huge
rearchitecture project here at $work, and there's a huge amount to do,
but also a huge amount of time, and a directive to nail down some of
these details, so there's a distinct possibility I can sneak it in.

>> In a perfect world,
>> I'd be using basically Perl6 syntax for classes and methods, and have
>> as little work to do as possible when we decide to upgrade to P6 (one
>> day).
>
> I think this is a red herring.  Method declaration syntax is going to be the
> least of your worries when upgrading Perl 5 code to Perl 6.

Well, I oversimplified that aspect a bit ... the truth is a bit more
complicated, and involves what I can sell my peeps on here at $work.
I have a fear-of-change contingency to deal with, you know?  And it's
a much easier sell when I say "look, we're using same syntax we'll
have to use anyway in P6!"

> I would prefer it was left in the MXMS/Perl 6 style for one concrete reason:
> overloading traits makes the meaning of the trait ambiguous.  You'll never
> know in "is Foo" if "Foo" refers to a class or a trait.  If somebody defines a
> class with the same name as a trait, what do you do then?  I hit this problem
> with Moose attributes, where types and classes share the same syntax.

Well, I was thinking that I had seen somewhere that that syntax was
okay in P6 for _something_, but maybe I'm misremembering, or it was in
an Apocalypse and got dropped, or somesuch.  But I take your point.
My solution was just going to be that get_type() returning undef would
be considered perfectly fine, but that's a bit hacky too.  So I
concede the point.  I was just trying to be creatively lazy anyway.
:-D

> The type *syntax* has never been in question.  What to use to resolve the type
> is the issue.  I don't want to saddle MS with Moose.  Any::Moose might be
> acceptable.

No, I agree that whatever it is, it needs to be an _extension_ to MS,
not incorporated into it directly.  People should have the choice as
to whether they want to use Moose types, some other kind of types, or
no types at all.

> I'd be happy if you wanted to alter the MS parser to handle MXMS/Perl 6 type
> syntax but with no default behavior.  Then you can use $sig->{type} to do your
> thing and later we can resolve what to do by default.

Hmmm ... that still puts other potential MS extension writers at the
mercy of whatever we parse (or don't parse).  Ideally, there would be
some hook into the parsing as well.  I can't think how that would work
right now, but I think it's worth discussing.

>> My second issue is that, as I mentioned, I would need to wrap
>> inject_from_signature.  But it looks to me like I can't override it
>> and just call SUPER because it's not actually a method (just a sub).
>
> You could fix that.

Well, sure.  That part would be easy, now that we're talking about me
modifying MS directly. :)

Okay, I'll think about this some more and see if I figure out how to
do some of this stuff.  Suggestions are much appreciated, of course.
:)


            -- Buddy