SMD is for weenies

2 views
Skip to first unread message

Yuval Kogman

unread,
Jun 30, 2005, 12:07:47 PM6/30/05
to perl6-l...@perl.org
As I understand it SMD is now not much more than a mechanism to
place a constraint on the MMD, saying that there can only be one
method or subroutine with the same short name.

Why is this the default?

MMD has a huge value for amending software (especially not your own
software) - specialized cases can be just added next to the generic
one, and they provide either:

a. a better interface for specific data
b. a better implementation for specific data
c. both

but since it is specialized it shouldn't be the one and only
short name - it's not generic.

So far so good?

method foo is unique ($param) {

}

From then on no possibly compatible shortnames can be added, and if
there were any,. it's also an error.

If there is any use for SMD besides uniquifying, please clarify it.

If not, please clarify why it should be the default for a module
author who hasn't thought about it - all it does is prevent me from
appending to his code conveniently.

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me has realultimatepower.net: neeyah!!!!!!!!!!!!

Sam Vilain

unread,
Jun 30, 2005, 9:42:34 PM6/30/05
to Yuval Kogman, perl6-l...@perl.org
Yuval Kogman wrote:
> As I understand it SMD is now not much more than a mechanism to
> place a constraint on the MMD, saying that there can only be one
> method or subroutine with the same short name.
> Why is this the default?

Otherwise you lose this quite useful warning if the signatures didn't
match;

method foo redefined at ...

I agree with you MMD is very cool, and I use it a lot. But I don't
mind clarifying the intent with "multi"; this "overloading" is
considered by some to be surprising to new programmers.

Sam.

Yuval Kogman

unread,
Jul 1, 2005, 12:27:07 AM7/1/05
to Sam Vilain, perl6-l...@perl.org
On Fri, Jul 01, 2005 at 13:42:34 +1200, Sam Vilain wrote:
> Yuval Kogman wrote:
> >As I understand it SMD is now not much more than a mechanism to
> >place a constraint on the MMD, saying that there can only be one
> >method or subroutine with the same short name.
> >Why is this the default?
>
> Otherwise you lose this quite useful warning if the signatures didn't
> match;
>
> method foo redefined at ...

That's a good point...

I'm guessing that the default warnings should have a warning for MMD
methods which append to a short name without appearing immediately
after each other in the same file.

> I agree with you MMD is very cool, and I use it a lot. But I don't
> mind clarifying the intent with "multi"; this "overloading" is
> considered by some to be surprising to new programmers.

Prepending 'mutli' is not a problem when I have to type it. It's a
problem when others won't type it. When 90% of the module code I'll
be using is not MMD compatible, because MMD is not the default, I
can't specialize other people's code without editing it (at runtime
or at the source level).

Overloading won't happen unless people overloading semantics are
introduced, and that's exactly what I'd like to do to other people's
code occasionally.

As for the suprising factor, I can argue that Perl 6 is surprising
already, and that overloading like behavior should not happen unless
people try to achieve it.

However, I'd expecet naive use of MMD to also work, since java and
C++ provide more primitive but like-minded tools themselves.

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &

/\ kung foo master: /me wields bonsai kittens: neeyah!!!!!!!!!!!!!!!!

Piers Cawley

unread,
Jul 6, 2005, 7:58:44 AM7/6/05
to Yuval Kogman, Sam Vilain, perl6-l...@perl.org
Yuval Kogman <nothi...@woobling.org> writes:

Then write yourself a module, call it 'multiplicity' say, which would allow you
to say

use multiplicity;

sub foo (...) {...} # foo is a multimethod, even if there's already a 'SMD'
# foo in existence.

It shouldn't even be that hard, just macroize sub/method/whatever to become
multis that first check if there's already a singly dispatched sub with the
same name and promoting to multi status if possible.

Of course, if you use something like that, you're taking the risks on your own
head, but you knew that as soon as you typed 'use multiplicity'.

The important thing is that the dispatch and reflection system should be
flexible enough to allow you to write something like this.

Yuval Kogman

unread,
Jul 6, 2005, 10:52:19 AM7/6/05
to Piers Cawley, perl6-l...@perl.org
On Wed, Jul 06, 2005 at 12:58:44 +0100, Piers Cawley wrote:

> Then write yourself a module, call it 'multiplicity' say, which would allow you
> to say
>
> use multiplicity;
>
> sub foo (...) {...} # foo is a multimethod, even if there's already a 'SMD'
> # foo in existence.
>
> It shouldn't even be that hard, just macroize sub/method/whatever to become
> multis that first check if there's already a singly dispatched sub with the
> same name and promoting to multi status if possible.
>
> Of course, if you use something like that, you're taking the risks on your own
> head, but you knew that as soon as you typed 'use multiplicity'.
>
> The important thing is that the dispatch and reflection system should be
> flexible enough to allow you to write something like this.

The issue is cultural, not technical.

If people expect SMD, use it, rely on it, MMD is just another
esotheric feature. Newbies' code will not exploit. Most of CPAN will
not be ready for it.

I won't write me such a module because it'll be more headache than
benefit - explaining to everyone that in my code I like everything
MMD.

What I'm claiming is that MMD like behavior should be the norm. When
it's not appended with true multiness, it's functionally identical
to SMD.

The issue is that extending another person's module with a
multimethod, and using type/parameter dispatch in order to
help code evolve better over time will never be a "good" or normal
thing to do if it feels kludgy.

My claim is that it doesn't need to feel kludgy.

A macro library kludging over a kludge is twice as kludgy as it was
before.

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &

/\ kung foo master: /me does a karate-chop-flip: neeyah!!!!!!!!!!!!!!

Stuart Cook

unread,
Jul 6, 2005, 11:03:18 PM7/6/05
to perl6-l...@perl.org
It's possible that we could do the following:

1) All subs (and methods) are considered multi 'under-the-hood'.

2) If the first declaration is explicitly 'multi', then you (or
others) can provide additional overloads (using 'multi') that won't
trigger warnings.

3) If the first declaration /doesn't/ use 'multi', then defining
another sub/method of the same name triggers an error/warning. BUT,
later declarations can override this by using some sort of special
declaration.


e.g.

sub foo(Int $x) { ... }
sub foo(Str $x) { ... } # error/warning

multi sub foo(Int $x) { ... }
multi sub foo(Str $x) { ... } # ok

sub foo(Int $x) { ... }
sub foo(Str $x) is overload { ... } # ok; not sure about the trait name


This provides uniqueness checking for SMD subs by default, while still
allowing hardcore hackers to overload other people's subroutines
without their explicit consent. It's not as clean as Yuval's
suggestion, but I think it might be more acceptable to folks who are
used to SMD.


Stuart

Reply all
Reply to author
Forward
0 new messages