Hong Zhang wrote:
How do you define the currently loaded? If things are lazy loaded,
the stuff you expect has been loaded may not have been loaded.
We could load placeholders that go and load the bigger methods
as needed, for instance.
--
David
At 06:34 PM 8/30/2001 -0700, Hong Zhang wrote:
With optimized C compiler, we can achieve similar performace
with obviously more code. Let's say C is only 80% of Fortran on math, I
still don't see the reason to put math into C language for the last 20% of
speed. It may be my personal preference.
If the dispatcher is drop-in replacable, what does its
interface look like?
I'm thinking this is either deep in mop territory, or a probably quite
straightforward set of decisions about dispatch tables, depending
on how you look at things.
I found just one relevant occurence of 'mop' in
What is the need for CLOS? Are we trying to build a kitchen
sink here?
To echo Michael, CLOS != multiple dispatch.
http://dev.perl.org/rfc/256.html
The usefulness of multiple dispatch depends on how intelligently the
dispatcher decides which variant of a multimethod is nearest to a
given
For example, here is an event handler for a GUI:
sub handle (Window $w, Event $e) : multi {
log(Unknown event $($e-desc) called on window
$($w-name));
}
sub handle (Window $w, CloseEvent $e) : multi {
$w-close;
}
sub handle
Me wrote:
I can imagine plausibly useful dispatch rulesets that do not involve
comparing sums of inheritance distances. (Though this *is* all
imagining as I haven't used multimethods/clos in about 10 years.)
I would also imagine that others see that summing inheritance
distances may not
Hong Zhang wrote:
3) The multi dispatch is generally slow and complicated. Since it does
not fit well with OO concept, it will just cause more confusion. Typically
we use different solution for OO language vs procedure language.
In other words, how much do we want our language to set up for
Dan observed:
I hadn't considered having it as a global thing, just because I can see
class Foo wanting multimethods, and class Bar being fine with 'normal'
class hierarchy walking, and class Baz deciding it wants the automatic
redispatch form of method calling.
We
Hong wrote:
Note that the handler that is selected depends on the *combination* of
the types of the two arguments. And that the dispatcher understands
the argument/parameter inheritance relationships and selects the most
specific handler for each combination. For example, a
Because multimethods are inherently an OO technique.
You can say so, but I am not buying it very much.
It doesn't. The multimethod consists of those variants that are currently
loaded.
How do you define the currently loaded? If things are lazy loaded, the stuff
you expect has been
On Thu, Aug 30, 2001 at 06:34:31PM -0700, Hong Zhang wrote:
None of them. That's why Class::Multimethods doesn't use CLOS's awful
left-most argument first resolution mechanism.
So what is the next step. How do you define the next most-matched methods.
Please look at how Class::Multimethods
I sure miss multi-dispatch.
http://dev.perl.org/rfc/256.html
Damian
Schwern explained:
# Following RFC 256
sub name (Foo $self) : multi {
return $self-{name};
}
sub name (Foo $self, STRING $name) : multi {
$self-{name} = $name;
return $self-{name};
}
which is quite a bit
13 matches
Mail list logo
