David Storrs wrote:
On Jul 8, 2005, at 4:25 PM, Dave Whipp wrote:
Rod Adams wrote:
multi method foo#bar (Num x) {...}
multi method foo#fiz (String x) {...}
$y = 42;
$obj.foo#fiz($y); # even though $y looks like a Num
$obj.foo($z); # let MMD sort it out.
Instead of changing the parse rules for #, why not just use a trait?
multi method foo is short_name('bar') {...}
I thought about that, but then thought that to become commonplace it was
a bit much to type. I also couldn't come up with a way to call a given
multi that matches on a given attribute, without adding even more
complexity to MMD.
Having additional tags might also give us something to hang priority
traits off: "foo#bar is more_specific_than(foo#baz);" might
influence the order of clauses in the implicit given/when block. It
feels like there should be a generalization of operator precidence
here (even thought he two are superficially dis-similar, the
looser/tighter concept appears valid).
Although I like the idea of reusing this concept, I'm not sure that
it really solves the problem. Fundamentally, we're trying to make
MMD behave intuitively with no programmer effort.
Well, if one views MMD as "a list of methods to try, each with it's own
requirements on it's arguments", then it can completely solve the
problem, along with a method sort function.
1) take all methods the user specified "higher than/lower than/equal to"
out of the mix.
2) sort remaining methods via a standardized function.
3) put all the ones taken out in step 1 back in, where they are requested.
4) scan the methods, in order, for the first that accepts the given
arguments.
5) dispatch to the chosen one in #4
-or-
6) begin AUTOMETHing, etc.
Then all we need is a DWIMish sort function.
Some ideas:
-- longer parameter lists go before shorter ones.
-- if param(n) of one ISA param(n) of another, it goes first.
-- slurpies after non-slurpies
-- a hashkey of the parameter types (for deterministic coin flips)
I'm not committed to what goes into the method sort function, or in what
order, just the concept of it. To me it seems easier to visualize than
distances, etc. If nothing else, it should be easy to explain to users
and programmers.
With the name tagging idea from before, one could then say things like:
multi sub foo#lastresort ([EMAIL PROTECTED]) is after(foo#default) {...}
for when the default sort does things incorrectly.
A reasonable extensions of this would be to have a coderef attribute
that determines if a supplied set of arguments is acceptable, rather
than the default check. This is a possible MTOWTDI for the 'where' clauses.
Then again, there are likely several glaring problems with this idea
that I'm just not seeing at the moment.
-- Rod Adams