HaloO,
Jonathan Lang wrote:
Bear in mind, though, that signatures include not only type
information, but also parameter names; and method calls are permitted
to pass an argument into a given parameter by means of its name
instead of its position, so the names cannot be disregarded. For
instance, consider the following pair of methods, supplied by
different roles:
method connect ( Terminal $from, Terminal $to ) { doit($from, $to) }
method connect ( Terminal $dest, Terminal $src ) { doit($src, $dest) }
Well, the type system would see these as a method that besides the
invocant has got two positional parameters of type Terminal and the
classes these things are composed into have to provide a method that
accepts these two. That's easy so far. But I see your point of the
argument names. So you can construct a role conflict and leave an
undefined method for the class. As long as users abide by the positional
interface they get what either role guarantees. When names have to be
available as well, then we get an undefined method that has to have two
positionals and two named parameters such that all four names appear
to satisfy all conceivable call sites for the two roles.
There's no automated means that would allow you to reliably merge
those two signatures in a semantically appropriate way - not until
perl is smart enough to know that "from" and "src" have similar
connotations. When you have a conflict like this, you're better off
dropping the signatures altogether and leaving it up to the guy
writing the new implementation to figure out what to do with the
arguments that he gets.
I don't know how close leaving an undefined method as described above
to the class designer comes to automated merge. Note that at no point
I'm arguing that the body be merged. I'm seeing guarantees that the type
system tries to hold up in favour of the users of roles.
Regards, TSa.
--
