Role-based testing seems very perl6ish. I'd suggest the role name be
"Invocable" with much the sort of signature as you've described.
That being said, I don't think that the current error is terrible. It
clearly shows that the issue is with the attempt to invoke a Bool.
Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.
On Mon, Nov 14, 2016 at 2:32 PM, Brandon Allbery <allber...@gmail.com>
wrote:
> This started out some weeks ago as a user in #perl6 confused by an error
> that gofled down to:
>
> [28 19:01:37] <geekosaur> m: my Bool $x = False; $x()
> [28 19:01:38] <camelia> rakudo-moar 0dc6f7: OUTPUT«No such method
> 'CALL-ME' for invocant of type 'Bool'
>
> This is, at the very least, LTA. But it also got me thinking about the
> spec.
>
> The obvious way to clean up the above, and some more complicated things of
> the same sort, is to hide the obviously-internal CALL-ME behind a role,
> which arguably should be part of the spec as well to let implementations
> provide a stable interface while doing whatever is necessary for the
> backend in its implementation. The obvious name for this role is Callable.
> But, we already have a role Callable which is a mixin that adds
> functionality to things that are callable, and is part of 6.c's spec. This
> seems like a design flaw, and looks like it's going to be hard to fix, or
> at least to make rational when other roles describe things that *are*
> something instead of describing what they *modify*.
>
> Is there a way forward on this that makes any sense?
>
> (for the record, the proposed wrapper role looks something like
>
> role OughtToBeCallable { # bikeshed pending paint job...
> method CALL(|c) {...}; # CALL-ME happens here
> }
>
> and the 4 places that currently build a CALL-ME in nqp would have a type
> OughtToBeCallable added so that the runtime CALL-ME error becomes a
> compile-time failed OughtToBeCallable constraint with a
> user-comprehensible error.)
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
