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

[Michael G Schwern]

On 2011.3.3 6:54 AM, Buddy Burden wrote:
> Hunh.  You're right ... _as MXMS implements it_, "does" is just a
> synonym for "is", which makes it rather useless.  That's not what I
> was talking about then. :)  I believe the way P6 uses it (and
> certainly the way that *I* would want to use it) is to check roles.
> After all, the whole point of the role is to have a more flexible
> solution for problems that are currently solved with inheritance.
> And, as chromatic so eloquently put in his blog essays on roles,
> sometimes duck typing just doesn't cut it.(*)  So if I'm using a role
> to guarantee that a class conforms to a given interface, don't I need
> a way to check that?
> 
>     method foo ($bar does Executable)
>     {
>         # now I know I can do this
>         $bar->exec();
>     }

It's a good idea, I'm sold on roles, and it makes sense to me.  It's something
that should be discussed with the list.  Fire off a different thread, because
I'm pretty sure nobody but us is reading this one.

I'm also not sure it's actual Perl 6 syntax.  I don't see any example of it
either in the Perl 6 synopsis or rakudo code.  Might just be in chromatic's head.


>> 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.
> 
> Actually the way I've done it thus far (I've officially started the
> hacking; woohoo!) is like so:
> 
>     use Method::Signatures { warn => 0 };
> 
> and that turns the warnings off.  Or we could come up with a different
> (or additional) interface if you like:
> 
>     use Method::Signatures qw<:NOWARN>;
> 
> perhaps.  I just kept things so I'd have to fiddle with import() as
> little as possible.
> 
> What I really wanted was something like:
> 
>     no warnings 'reserved';              # or other appropriate category
> 
> but I couldn't get that to work, so I went with the above.  But it's
> simple enough to change if you have a preference.

I'm happy with it just dying.  I'd rather see time spent implementing the
unimplemented behaviors than elaborate ways to configure them when they're
missing.  If that's your itch, ok.

I like `use Method::Signatures { warn => 0 };` because it can translate
directly to passing those parameters straight along to the internal object.
That keeps us from having to write more import syntax for everything we want
configurable.


>> 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.
> 
> Okay, cool.  That's what I'll do then.  Seeing as how I just changed
> the way invocant parsing works (it was conflicting with a class type
> on the first parameter), I'd say this work qualifies as both new
> feature _and_ scary bug fix. :-D  So I'll turn my clone into a branch
> and we'll go from there.
> 
> Thanks for all the guidance!

y/w!  And thank you for the work.


-- 
124. Two drink limit does not mean first and last.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
           http://skippyslist.com/list/