On 2008-Oct-22, at 10:03 am, TSa wrote:
David Green wrote:
One thing I would like signatures to be able to do, though, is assign parameters by type. Much like a rule can look for identifiable objects like a <block> or <ident>, it would be very useful to look for parameters by their type or class rather than by name (or position).

Note that types have a fundamentally different task in a signature than name and position have. The latter are for binding arguments to parameters. The types however are for selection of dispatch target.

Names do that too; I think both names and types should be available for both binding and dispatching, depending on what's more natural in a given context. Sometimes we think in terms of names (I'm going to Fred's place), sometimes in terms of types (I'm going to the grocery store). (And some types are names (Dad)!)

In single dispatch it is very important if your dispatch is handled in the Nail or Hammer class. In multi dispatch one can still distinguish &action:(Hammer,Nail) from &action:(Nail,Hammer). There is the following syntax to define two sigs for the same body

   multi method action (Hammer $hammer, Nail $nail)
                      |(Nail $nail, Hammer $hammer)

Sneaky, I hadn't thought of doing it that way. Of course, a mere five objects give you an unwieldy 120 possibilities, so some syntactic relief is called for. Perhaps something like an & to indicate that the parameters are not sequential:

sub foo ($posn0, $posn1, Bar $type1 & Baz $type2 & Bat $type3, : $named1, :$named2)


Reply via email to