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

[Michael G Schwern]

On 2011.3.2 10:43 AM, Buddy Burden wrote:
>> 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.

The only way the invocant will be messed up is if you deliberately subvert the
normal method call process.

    my $obj = A::Totally::Different::Class->new;
    $obj->Some::Class::method(@args);

This is something you're highly unlikely to do by accident.

There's people passing the wrong arguments by mistake, and then there's people
deliberately passing the wrong invocant.  I'm concerned with helping catch
mistakes rather than stopping people who really want to do something crazy.

Since implicitly type checking the invocant adds overhead to every method
call, it's not worth punishing everyone with speed loss just to try and stop
those who deliberately want to subvert the type check.


>> 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.

I'm not fond of it either.  And it's tied up with the metaclass object, so
it's not clear how useful it is in Perl 5.


>> 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. :)

Sorry, I'm using up all my brilliant thoughts on Test::Builder2 and my current
client's $work.


>>> *) 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 sure?  That's isa and does in Moose... but the MXMS traits are unrelated
to types and roles, no?  You are talking about this:

   Traits
           method foo (Affe $bar does trait)
           method foo (Affe $bar is trait)

       The only currently supported trait is "coerce", which will attempt to
       coerce the value provided if it doesn't satisfy the requirements of the
       type constraint.

or something else?  From the above, I read does and is as synonyms for
applying traits.


>> 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.)

...I'm split.  A warning at least lets the code work... but the only way to
silence the warning is to either remove the type check or fix your types... so
it might as well be an error...

Since Method::Signatures is lexical, I don't see how you'd write code with a
feature if you didn't intend to use it.  I'd go with an error.  At least you
can easily trap an error.


> 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. :)

Yeah.  You're a committer now so there's no point in forking and merging pull
requests is more work for me (or you).

As for branching or working on master, use your head.  Keep master working.
New features or scary bug fixes go into a branch.  When in doubt: branch.

But by cloning you're always working in your own local branch.  Nothing is
committed until you push.  So often you can just work on master in your own
clone, do a bunch of commits, and then push when it's ready.  And as long as
you haven't pushed you can always turn your local commits to master into a branch.


-- 
Life is like a sewer - what you get out of it depends on what you put into it.
    - Tom Lehrer