> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> And I don't see what's stopping someone from writing Dispatch::Value.
>
> use Dispatch::Value;
> sub foo($param is value('param1')) {...}
> sub foo($param is value('param2')) {...}
>
> What it seems you're wanting is it to
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> What it seems you're wanting is it to be in the core. And I'm saying
> that's irrelavent. There are thousands of great ideas out there, and
> they can't all fit into Perl's core. That's why there's thousands of
> modules on CPAN.
H
Adam Turoff writes:
> On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> > It will still have a lot of power in text processing, and still be a
> > powerful "quicky" language, but that's no longer its primary focus --
> > not to say that highly structured programming is. Some applicati
On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> You must not be following Perl 6 closely enough, then. Perl 6 is a
> "real" programming language now, as opposed to a "scripting" language.
Um, I've followed Perl6 closely enough to know that the distinction
between "real langauge" an
[EMAIL PROTECTED] (Luke Palmer) writes:
> It will still have a lot of power in text processing, and still be a
> powerful "quicky" language, but that's no longer its primary focus --
> not to say that highly structured programming is.
So, uh, what is?
> And you can still do it the Perl 5 way in P
> Apologies if I've missed some earlier discussions on multimethods. The
> apocolypses, exegesises and synopses don't seem to say much other than
> (a) they will exist and (b) wait for apocolypse 12 for more information.
>
> Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
>
Apologies if I've missed some earlier discussions on multimethods. The
apocolypses, exegesises and synopses don't seem to say much other than
(a) they will exist and (b) wait for apocolypse 12 for more information.
Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
intent is t
At 9:27 PM -0400 9/4/02, Ken Fox wrote:
>Dan Sugalski wrote:
>>At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>>>So, just to clarify, does that mean that multi-dispatch is (by definition)
>>>a run-time thing, and overloading is (by def) a compile time thing?
>>
>>No. They can be both compile ti
Dan Sugalski wrote:
> At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>> So, just to clarify, does that mean that multi-dispatch is (by
>> definition)
>> a run-time thing, and overloading is (by def) a compile time thing?
>
> No. They can be both compile time things or runtime things, dependin
Dan Sugalski wrote:
>> Dan, can you explain what "multimethod dispatch" is?
>
> Damian can explain it better than I can,
I thought you did a great job!
However, anyone who wants to know more about multiple dispatch
might also like to read:
http://www.sama
rameters (which Java
calls the "signature" of the method). I believe this is what has
been referred to as "multimethod dispatch" on this thread.
An "overridden" method is two methods with the same name AND type
signature in two different classes, where one class is a
convertToJPEG() and convertToPNG(), but that's the whole
point of overloading and multimethod dispatch, isn't it?
The usual list context / scalar context distinction would of course still be possible.
It's just about _extending_ context sensivity.
[Comments | Suggestions | Criticism] welcome.
At 7:31 AM -0700 9/4/02, David Wheeler wrote:
>On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
>
>>No. They can be both compile time things or runtime things,
>>depending on the characteristics of the language.
>
>So if it's compile-time for a given language, how is it differen
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
> No. They can be both compile time things or runtime things, depending
> on the characteristics of the language.
So if it's compile-time for a given language, how is it different from
the Java concept of overloading?
And will
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>
>From: Ken Fox [EMAIL PROTECTED]
>> Over loading is what C++ has. It is not the same as
>> multi-dispatch. The trouble with over loading is that the
>> compiler uses static (compile-time) type information to
>> select the over loaded method.
From: Ken Fox [EMAIL PROTECTED]
> Over loading is what C++ has. It is not the same as
> multi-dispatch. The trouble with over loading is that the
> compiler uses static (compile-time) type information to
> select the over loaded method. This can create subtle
> bugs when people try to re-use code
David Wheeler wrote:
> Ah, yes, the same thing exists in Java. I remember, now.
I thought Java only has over loading?
Over loading is what C++ has. It is not the same as
multi-dispatch. The trouble with over loading is that the
compiler uses static (compile-time) type information to
select the o
On Tuesday, September 3, 2002, at 06:12 PM, Dan Sugalski wrote:
> Damian can explain it better than I can, but it's essentially when you
> dispatch based on sub or method signature. You're allowed to have
> multiple versions of a single sub as long as they differ in their
> parameter signatur
At 5:41 PM -0700 9/3/02, David Wheeler wrote:
>On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote:
>
>>We call that concept "multimethod dispatch". That's what you're asking for.
>
>Dan, can you explain what "multimethod dispatch" i
On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote:
> We call that concept "multimethod dispatch". That's what you're asking
> for.
Dan, can you explain what "multimethod dispatch" is?
Thanks!
David
--
David Wheeler
22 matches
Mail list logo