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 01:27 PM 9/4/2001 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > It'll probably be something like "Here's the function name. Here's the
> > parameters. Do The Right Thing." I don't think there's much need for
> > cleverness on the part of the interface. The actual dispatch code could b
David L. Nicol wrote:
> How about some nice introductory links for MOP theory? The
> above-linked post is also the only time I recall seeing aspect
> theory mentioned in here either. Someone explained aspectJ to
> me at a PM meeting and it sounded like a sure recipe for
> completely impossible A
Me wrote:
> I found just one relevant occurence of 'mop' in perl6-all archives:
>
> http://www.mail-archive.com/perl6-all@perl.org/msg10432.html
>
> And not a single reply...
>
> I'd really like to see what Dan / lisp folks have to say about mops
> and perl6...
How about some nice introductor
Dan Sugalski wrote:
> It'll probably be something like "Here's the function name. Here's the
> parameters. Do The Right Thing." I don't think there's much need for
> cleverness on the part of the interface. The actual dispatch code could be
> nasty, but that's someone else's problem. :)
>
>
At 04:09 PM 8/31/2001 -0500, Me wrote:
> > 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.
It'll
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 preferen
> 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 perl
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::Multi
> > It doesn't. The multimethod consists of those variants that are currently
> > loaded.
> >
> How do you define the currently loaded?
Accessible in the program's symbol table and registered with the multimethod
dispatcher.
> >> 2) If there is mismatch on more than one
> 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
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 examp
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 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 f
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
> 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;
> }
>
>
On Thu, 30 Aug 2001, Damian Conway wrote:
>> Even if the dispatcher is the heart of multimethods, perhaps it
>> would be nice if it were convenient to replace the dispatcher
>> in whole or part.
>
> I'm sure if we asked Dan nicely, he'd consider hanging the dispatcher on
> a lexicall
> Even if the dispatcher is the heart of multimethods, perhaps it
> would be nice if it were convenient to replace the dispatcher
> in whole or part.
I'm sure if we asked Dan nicely, he'd consider hanging the dispatcher on
a lexically-scoped hook to make that possible ;-)
Damian
> 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
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 q
On Wed, Aug 29, 2001 at 10:49:25PM -0700, Hong Zhang wrote:
> What is the need for CLOS? Are we trying to build a kitchen
> sink here?
Umm, I think you mean "What's the need for multiple dispatch?"
Currently, if I want to write a method that does this:
my $name = $foo->name;
$foo->name(
What is the need for CLOS? Are we trying to build a kitchen
sink here?
Hong
> -Original Message-
> From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 29, 2001 9:43 PM
> To: [EMAIL PROTECTED]
> Subject: CLOS multiple dispatch
>
>
>
> > I sure miss multi-dispatch.
http://dev.perl.org/rfc/256.html
Damian
is of course the Common List Object System, and feeding
"CLOS multiple dispatch" into a search engine gives more
theses than you can shake a dry-erase marker at.
--
David Nicol 816.235.1187
KAK OH CKA3AT
24 matches
Mail list logo
