HaloO,
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).
For example, if I ask you to hand me a hammer and a nail, I don't need
you to hand them to me in a specific order, or with labels attached like
a Dick Tracy comic, in order to know which is which. That's obvious,
because, well, one is a hammer and one is a nail. If I'm writing
OO-code, then Perl also knows what's a Tool::Hammer and what's a
Fastener::Nail -- if I know that my $tool is a hammer, and Perl knows,
then I shouldn't have to spell it out.
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.
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)
{...}
which achieves your goal of typed binding. This explicit form has
replaced the 'is commutative' trait which was easier than naming
the n! sigs for a routine with n parameters. This is somewhat
unperlish. OTOH, an 'is commutative' on a six parameter multi
looks innocent whereas a routine with 720 sigs is impressive.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
