[Perl5-syntax] How to test for a role in a method signature

[Reverend Chip]

On 3/4/2011 4:00 PM, Piers Cawley wrote:
> On Fri, Mar 4, 2011 at 7:24 PM, Reverend Chip <rev.chip at gmail.com> wrote:
>> On 3/4/2011 3:06 AM, Piers Cawley wrote:
>>> On Fri, Mar 4, 2011 at 10:29 AM, Reverend Chip <rev.chip at gmail.com> wrote:
>>>> On 3/4/2011 1:57 AM, Piers Cawley wrote:
>>>>> On Fri, Mar 4, 2011 at 7:16 AM, Reverend Chip <rev.chip at gmail.com> wrote:
>>>>>> On 3/3/2011 10:32 PM, Piers Cawley wrote:
>>>>>>> Personally, I prefer the flow of 'Typed $parameter does coerce', where
>>>>>>> the constraint declaration is always to the left of the parameter name
>>>>>>> and the right hand side is for declaring stuff about how the parameter
>>>>>>> is initialized. I would encourage anyone wanting to constrain by type
>>>>>>> to declare a type along the lines of "subtype DoesRole, as role_type
>>>>>>> 'Role'" ...
>>>>>> No, I don't buy it.  The "isa" and "does" tests are so fundamental and
>>>>>> common that forcing people to type that much to get the test would
>>>>>> violate Huffman.
>>>>> That's why I think that the better solution is to delegate to the
>>>>> package to find out if a particular value satisfies it. If the package
>>>>> is a class, then obviously it does an 'isa' test, if a role, then it
>>>>> does a 'does' check and, if a type constraint, it uses the type's
>>>>> constraints.
>>>> And for combining?  You only get one name to the left.
>>> If you _really_ want to ensure that a parameter isa Foo and also does
>>> Bar then you need to rethink your architecture. Or hide the pain, bite
>>> the bullet and make a custom type.
>>>
>>> Easy things should be easy. Hard things should be possible. Stupid
>>> things should be discouraged.
>> I was thinking of does Foo and does Bar, actually.  But there is no way
>> at compile time to know which test will apply, so your proposal is
>> slower at runtime.  That's a killer.
> And down that road lies C++. Let the constraint (be it a role, a class
> or a moose type) decide what tests to run. You pay the cost of a
> method call and get more convenient syntax. How do you plan to signal
> that a parameter should be coerced?

Let me first observe that this is a fundamental separation in how people
generally see function declarations - it happened with C, and it's
happening here.  Should they be descriptive or coercive?  Should they
just examine the values, or modify them?  In C, the coercive won, and on
balance I think that was OK.  But I favor the descriptive as default in
Perl, because Perl doesn't make programmers make trivial things like
integer size emerge as types; Perl coercions are heavyweight and so we
should have to ask for them.  Therefore in my world, coercion would not
be the default ... though all is fair if you predeclare.

So I would propose:
    use Method::Signatures { coerce => 1 };   # to change the default
and
    method foo (Int $x is coerced)   # if it's not the default
    method foo (Int $x is uncoerced)   # to reverse a default
I'm sure I could come up with something more clever but that's what I
see now.