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

[Piers Cawley]

On Sat, Mar 5, 2011 at 3:23 AM, Reverend Chip <rev.chip at gmail.com> wrote:
> 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.
>
>
>