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

[Buddy Burden]

Michael,

>> Well, potentially, yes.  I was just imagining that there might be some
>> cases where you might want to replace code instead of adding to it ...
>> for instance, one might want to replace the whole kit and kaboodle
>> with a call to MXPV's validated_list or somesuch.  So I thought it
>> might be nice to allow for that.  But if you don't like it, that's
>> cool by me.  It won't impact anything I personally want to do,
>> certainly.
>
> I'd like to hold off on that until we have a real use case.  Because it seems
> dangerous and because lacking a catch all it will drive us to do things better.

Fair enough.

> For example, I would like to see the joining of the code separated out.  And
> the code generators for various pieces split out like inject_for_type().

Yes, good point.

> Anyhow, runtime performance is important.

Absolutely agreed.

>> But I personally agree with you _mostly_ that you usually don't want
>> to type check the invocant.  The only thing it's nice for is making
>> sure class methods aren't called as object methods, and vice-versa.
>> So I typically declare my class methods as:
>>
>>     method do_the_thing_with_the_thing (Str $class: Int :$other_param,
>> Str :$etc)
>
> Object methods being called as class methods: agreed, bad.
>
> But I don't have a beef with class methods being called as object methods.
> Class->class_method and $obj->class_method are functionally equivalent.  I
> don't think denying that will catch real bugs compared to the effort.

Well, a couple of things about that:

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

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

> IMO the type of the invocant would always be inferred.  You should not be
> allowed to explicitly set the type.

Well, if we're trying to roughly mimic P6 syntax, setting the type of
the invocant is definitely allowed.  See Synopsis 12
(http://perlcabal.org/syn/S12.html#Methods).

But I don't really have a horse in this race.  If we decide that
typing on the invocant is allowed, I'll use it (for class methods
only).  If we decide it's not, I won't miss it. :)

> The type of the invocant of a class
> method is not a string, but a class or subclass of the package in which the
> method was declared.  That $invocant is a string and $invocant->isa(__PACKAGE__).

I just know declaring it as a Str is how to make it work with MXMS. :D

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

> Could be.  Extracting inject_for_invocant() would give you the control you need.

Fair point.

> I think what I'd like instead of parse_extra (same issues as inject_extra) is
> this...
>
> I agree with most of the MXMS syntax, just not with the implementation.  And
> I'd like to bring the syntax of the various signature modules together.  So if
> you want does and coercions and all that, patch them into MS.  I would
> particularly like constraints (ie. "where").  This would improve MS for
> everybody and MS doesn't have to worry about supporting 3rd party parser hacks.

Hmmm.  My hesitation there is a few things:

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

*) If there's any extra overhead in parsing all the extra stuff,
people pay that whether they use it or not.  That's probably
insignificant, though.

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

But, again, these are all philosophical points from my POV.  None of
it impacts what I specifically want to do, so I don't really care that
much.

> I was considering also making MS more configurable about its features.  For
> example, a lot of people don't like that it declares the methods at compile
> time like a normal sub.  That could be turned off by passing a flag to
> import() which would pass that along to the object.  I was thinking about
> using it also for syntax... but I don't think I want to get into optional
> syntax, just optional behaviors.

The only things like that I was thinking was that it might be nice to
be able to change "method", "func" and/or "self" (similar to how
Method::Signatures::Simple does it).  Which would be fairly trivial to
implement.  Again, _I_ wouldn't use it, but it seems like others
might.

> Another example is a flag to control how types are checked.  For example, MS
> could ship with a purely class based type check on by default (fast and no
> dependencies) with the option to turn on a Mouse/Moose based one.

Sure, that would save the need for the vast majority of people to
subclass.  Depends on how much you want to build into MS directly, or
if you want to build in some sort of plugin structure, which might be
more work than you really want to get into.

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


            -- Buddy