On Mon, Sep 29, 2003 at 10:00:09AM -0400, Dan Sugalski wrote:
> So, I've two options:
>
> 1) When one or both of the classes a MMD function is installed for don't
> exist, we give them both class numbers (but don't load them) so when the
> classes *are* later loaded they already have numbers
>
>
On Mon, Sep 29, 2003 at 10:28:25AM -0400, Dan Sugalski wrote:
> On Mon, 29 Sep 2003, Mark A. Biggar wrote:
> > Isn't there also the option to force load the missing class(es)
> > recursively?
>
> We could, but I don't want to do that here. Just because a PMC class
> presents functions for other P
On Mon, 29 Sep 2003, Mark A. Biggar wrote:
> Dan Sugalski wrote:
>
> > Okay, here's an issue for everyone. I'm writing the MMD subsystem, at
> > least the parts needed for operator overloading, and I'm coming across the
> > need to defer adding functions. For example, the Float class has functions
Dan Sugalski wrote:
Okay, here's an issue for everyone. I'm writing the MMD subsystem, at
least the parts needed for operator overloading, and I'm coming across the
need to defer adding functions. For example, the Float class has functions
for the Integer class, and vice versa, and we can't guaran
> 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
>
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.samag.com/documents/s=1274/sam050
The specific definitions of these terms vary from language to
language. In Java, for instance, a method is said to be
"overloaded" and/or "overridden".
An "overloaded" method is actually two or more methods with the
same name but differing numbers/types of parameters (which Java
calls the "signa
Just some thoughts (and an idea):
I have found the whole context thing in Perl5 easier to understand when I regard it as
overloading based on the return type. We all know that languages like C, C++ and Java
throw a compile-time error if two function
definitions differ in their return type only
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" is?
Damian can explain it better than I can, but it's
On Thu, Mar 07, 2002 at 09:50:01PM +, Tim Bunce wrote:
> On Thu, Mar 07, 2002 at 01:48:49PM -0500, Dan Sugalski wrote:
> > Someone said:
> >
> > >First, there are basic native types such
> > >as num, int, and string, which I'm perfectly fine with. But what bothers
> > >me is the fact that big
a of kernal or CPU memory.
-Corwin
/*
Corwin Brust
corwin.dreamcafe.com
*/
- Original Message -
From: "Michel J Lambert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 07, 2002 4:46 PM
Subject: Re: Multimethod dispatch for parrot?
> > Yes. We wil
> Yes. We will, for actual method and sub dispatch. Not for the other
> vtable methods, though.
I guess my big 'complaint' was against using vtables for the variety of
operators, due to the inherent asymmetry in them. I knew Perl6 is going to
have MMD, but I didn't know how deep that support is g
With the possibility of making this thread off-topic: isn't multi-method a
function that propogates according to the values of more than one
argument? Like:
sub myfunc
{
my ($a, $b) = @_;
if ($a->isa('Vector3') && $b->isa('Vector3'))
{
return Vector3::myf
On Thu, Mar 07, 2002 at 01:48:49PM -0500, Dan Sugalski wrote:
>
> >First, there are basic native types such
> >as num, int, and string, which I'm perfectly fine with. But what bothers
> >me is the fact that bigint's and bignum's are being given a special place
> >in the vtable.
>
> Why? They're
At 11:51 AM -0500 3/7/02, Michel J Lambert wrote:
>I was curious if anyone has ever considered implementing multimethod
>dispatch (MMD) directly into parrot.
Yes. We will, for actual method and sub dispatch. Not for the other
vtable methods, though.
>In my opinion, this would provide
>several b
Michel J Lambert:
# I was curious if anyone has ever considered implementing multimethod
# dispatch (MMD) directly into parrot. In my opinion, this would provide
# several benefits over the current system. While (IMHO) MMD
# provides many
# benefits over the current system in terms of extensibilit
31 matches
Mail list logo
