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

[Buddy Burden]

Michael,

>> *) From a strictly philosophical standpoint, I think that $obj->foo()
>> and Thing->foo() are saying different things.  Even if $obj->foo()
>> works, functionally, I don't actually want my coders saying
>> $obj->foo() if they really meant Thing->foo().  It makes their code
>> harder to maintain, IMHO, because it implies something's going on
>> that's different from actually _is_ going on.
>
> I don't disagree on the principle, just the magnitude of the problem.  I don't
> think it's even worth:
>
>    my $class = ref $obj;
>    $class->method();

Okay, fair enough.

>> *) From a practical standpoint, it _could_ produce a bug, unless the
>> class methods are carefully written.  For instance, this:
>>
>>     method foo ($class: Int $arg)
>>     {
>>         no strict 'refs';
>>         my $func = "${class}::bar";
>>         return $func->($arg);
>>     }
>>
>> wouldn't work if called as $obj->foo().  How likely that is in
>> practice, I'm not sure; I've written something similar before, but
>> admittedly it was more tricky than typical.
>
> Again, no disagreement on the principle.  I don't think it's worth the runtime
> overhead.

Okay, but how is type-checking the invocant worse than type-checking
the parameters?  I mean, I hear you about MXMS and all that, and I'm
certainly not saying I don't believe you, but I just don't understand
_how_.  You know what I mean?

Again, though, this is not because I really really want to implement
type-checking on the invocant.  More for my own edification, and
because I think it would be moderately _nice_ to have it.

>>> What's missing is the ability to differentiate between class and object methods.
>>
>> Sure, if you think there's a better way, I'm certainly open to it.
>
> Perl 6 has the "method ^foo" syntax.
> http://perlcabal.org/syn/S12.html#Class_methods

Hunh.  I'm not fond of that synxtax _personally_, but if it's going to
be official P6 syntax, I suppose we could parse it.  Seems trivial
enough to do so.

>> *) It means that we're declaring that this module is providing the One
>> True Way for parsing signatures. You don't like the code we generate?
>> That's okay, you can provide your own.  You don't like the syntax we
>> parse?  Tough cookies buster!  I mean, obviously people can write
>> their own module.  It just seems weird to provide extensibility in one
>> area but not the other.
>
> Not providing the One True Way for parsing, MXMS has its own parser for
> example, but converging on the One True Syntax.

Heh.  Subtle distinction, but important, agreed.

> One of my goals is to converge the various signature modules into an agreed
> upon syntax and behavior for Perl 5 signatures which can ultimately be
> implemented in Perl 5 itself.  We are, essentially, acting as a prototype for
> future versions of Perl 5.

I'm intrigued by what you say and would love to receive one of your
pamphlets. :-D

> Anyhow, I don't so much mind the idea of an extensible parser as the
> implementation of parse_extra().  Just handing out the prototype and saying
> "go at it!" doesn't seem maintainable.

Yeah, I sort of just tossed that out there.  Nothing better was
springing to mind ... I sort of hoped you'd have something brilliant
in your back pocket. :)

>> *) It seems weird to me to accept syntax that you don't do anything with.  So
>>
>>     method foo ($debbie does Dallas)
>>
>> doesn't generate a syntax error, but doesn't actually do what you
>> thought it did.  Sort of a silent failure.
>
> Oh, I guess I didn't make that clear.  We'd implement "does" (it's just a
> synonym for "is", right?) and where and the rest.  Even types can be
> implemented with isa() and stealing from
> Moose::Util::TypeConstraints::OptimizedConstraints.

"is" checks inheritance, whereas "does" checks role composition.  So
they're not quite synonyms.

> You're right that if MS doesn't implement syntax, it should die or warn rather
> than silently ignore it.

Okay, so instead of having those methods in the base class be empty,
just have them spit out warnings?  Yeah, I could get behind that.
(Errors seem like overkill, but warnings are definitely appropriate:
Warning! Your syntax isn't really doing anything here; sorry about
that.)

>>> If you tell me your Github ID I can add you as a collaborator.
>>
>> I'm barefootcoder (most everywhere).  I'm still a total git newb tho;
>> just giving you fair warning. :)  I just managed to get the $work
>> folks converted over to svn a couple of years ago. ;->  But I did get
>> my github login a while back, so I'm good to go there.
>
> Ok then, you're all set.  We've talked about a bunch of stuff here.  Implement
> away!  Be bold, I can always roll your changes back.  Just don't force a push
> and you'll be fine.
>
> My only request is you post an issue before you add a feature or make a major
> change.  You don't have to wait for a reply, it just gives everyone an idea
> what's going on.

Okay, total git n00b question: should I fork, or just clone and
branch, or ... ?  I did some Googling around, but it looks like
different people have different ways of doing things, so I just
thought I'd ask. :)


            -- Buddy