HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
"Candidate set" would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next candidate on the list. Therefore, there
is a list.
Hmm, the term candidate should be after the applicability check and
before specificity check. The latter results in a partially ordered
list of targets. If there's more than one most specific target, we
have an ambiguity error. As a consequence there might not be a unique
next method on the target list and a nextsame might fail. I agree
that the synopsis conflate these details into the term "candidate list".
But I hope you are more rigorous.
What about ordinary methods (and ordinary parameters of multis)?
Does the candidate list hold every method name that matches, or does
it do simpler parameter matching based on number of arguments,
required named arguments, etc.?
There is hopefully a complete specification what constitutes
applicability. There can hardly be differing simpler versions.
In other words there is only one subtype relation that is used
whenever a binding takes place.
I have no idea what you said.
OK, here's my vision of dispatch. First there's a syntactic distinction
between MMD and class dispatch.
$obj.meth(|$args);
meth $obj: |$args;
These pull out the candidate set from $obj. Everything else
collects the candidate set from a namespace scan. Next, all candidates
are checked to allow a binding of $obj and |$args. The ones that
fail are dropped. If the candidate set is now empty we have a failure.
The remaining set is now sorted into a list of sets by applying the
subtype relation in the dispatch relevant parameter positions. If the
first element of that list is a set with a single element we have a
successful dispatch. Otherwise there's an ambiguity error. The .? avoids
the no target error, .+ avoids the ambiguity error and .* never fails.
I would leave the order in which sets of targets are called unspecified.
If one needs more control the .WALK method can be used. If class
dispatch fails because there's no applicable method then a MMD is
attempted.
I guess the answer to your question concerning hiding a method in a
derived class depends on the set of candidates the $obj.HOW comes up
with in the first step. If it delivers superclass methods and subclass
methods fail the applicability test then the dispatch goes to a
superclass method that can handle the dispatch. Would you favor a
type error then?
If that is the case, then a derived method might not hide a base
class method if the parameter list is seriously incompatible.
That is a natural and welcome consequence of type based dispatch.
Classes are for implementation sharing, not for transitive typing.
I'm talking about non-multi's here.
Me too. As stated above the candidate set is up to the class that
created the object. If this class can prevent the failover to MMD
I don't know.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
