=begin pod

=TITLE class WhateverCode

=SUBTITLE Code object constructed by Whatever-currying

    class WhateverCode is Code { }

C<WhateverCode> objects are the result of L<Whatever>-currying. See the
L<Whatever> documentation for details.

When you wish to control how a method or function interprets any
I<Whatever stars>, you may use multi dispatch with C<Whatever> and
C<WhateverCode> parameters to do so, as in the following example:

    class Cycle {
          has $.pos;
          has @.vals;
    }
    
    multi sub get_val(Cycle $c, Int $idx) {
          $c.vals[$idx % $c.vals.elems]
    }
    
    # Define what to do with a stand-alone * as the second argument
    multi sub get_val(Cycle $c, Whatever $idx) {
        get_val($c, $c.pos);
    }
    
    # Define what to do with a * in an expression
    multi sub get_val(Cycle $c, WhateverCode $idx) {
        get_val($c, $idx($c.pos));
    }
    
    my Cycle $c .= new(:pos(2),:vals(0..^10));
    
    say get_val($c, 3);   # 3
    say get_val($c, *);   # 2
    say get_val($c, *-1); # 1

Since C<WhateverCode> objects are C<Callable> you may use introspection
to create as fancy a behavior as you wish.  Continuing the following
example we may add handling for two I<Whatever stars>:

    # Define what to do with two * in an expression
    multi sub get_val(Cycle $c, WhateverCode $idx where { .arity == 2 }) {
        get_val($c, $idx($c.pos, $c.vals.elems));
    }
    
    say get_val($c, * + * div 2); # 2 + 10/2 = 7

Note, though, that subexpressions may impose their own I<Whatever star>
rules:

    my @a = (0,1,2);
    say get_val($c, @a[*-1]) # 2, because the star belongs to the Array class

This can make the ownership of I<Whatever stars> become confusing rather
quickly, so be careful not to overdo it.

=end pod
