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

[Michael G Schwern]

On 2011.3.4 12:10 PM, Buddy Burden wrote:
>> 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.
> 
> Oh, I already did it (did it back on Tuesday, actually).  The thing
> about dying is that it's _not_ actually easier to trap, since it
> happens at compile time.  E.g. in many of my tests, I've had to eval
> the method declarations as a string.  Which is fine for tests, but
> ugly if you had to do that in code.  So I think even if we change the
> warn to a die, we'll still want to have a parameter to turn it off.
> 
> I don't much care either way.  We can do warn, we can do die, or we
> can do either, depending on the 'use' call.  Your choice.  It's pretty
> trivial to implement it any of those ways now that I have all the
> tests working.

If you're declaring named methods, MS is going to yell at you immediately at
compile time and you're going to fix whether it's a warning or an error.

I think the only time this will really matter is if your code generates
anonymous methods on the fly.  In that case, you can trap the error.

The reason you'd want a warning is so you can write methods using features
that aren't implemented.  The argument is that the features of MS are all
restrictive and not having them work doesn't change how the code works.  But
we don't have a real use case for why you'd want to do that.  And we don't
plan on leaving anything unimplemented.

So just die.


>> 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.
> 
> Sure.  I'm just more used to
> 
>     use Method::Signatures ( warn => 0 );
> 
> style.  But, as I say, I didn't want to hack up import() to the point
> where it would support that, so I just stuck with the hashref.

Yeah, same reason you'd pass a hash ref into a method than a hash.  It leaves
the syntax open for the future.


-- 
There will be snacks.