Leopold Toetsch wrote:
Rod Adams <[EMAIL PROTECTED]> wrote:
If I were to need a different policy for a given method .bar, I would
likely create something called .bar much like your "run_random_bar",
which then dispatches amongst methods I name something like ._bar .
I see some detractions t
Rod Adams <[EMAIL PROTECTED]> wrote:
> If I were to need a different policy for a given method .bar, I would
> likely create something called .bar much like your "run_random_bar",
> which then dispatches amongst methods I name something like ._bar .
> I see some detractions to this approach:
> 1)
Leopold Toetsch wrote:
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...} #
[EMAIL PROTECTED] wrote:
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...}
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Thu, 10 Mar 2005 10:53:11 +0100
Rod Adams <[EMAIL PROTECTED]> wrote:
> It seems to me that there are several advantages to making a group of
> multi with the same short name a single object, of type
> MultiSub|MultiMethod, which int
Rod Adams <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>Discussion seems to have went off into esoteric cases of locally
>>overriden dispatcher policies and what not.
> I don't think it's as esoteric as you might think. Consider:
> package Foo;
> use MMD::Random;
> our &bar
Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>1) is there a MultiSub object with one short name that holds all
>possible long names (and function references)?
>If yes, who is creating it: the Perl6 compiler emits code to do so or
>it's up to
David Storrs wrote:
On Thu, Mar 10, 2005 at 02:22:20PM -0600, Rod Adams wrote:
David Storrs wrote:
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
use Foo; # from above, exports &bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect thi
On Thu, Mar 10, 2005 at 02:22:20PM -0600, Rod Adams wrote:
> David Storrs wrote:
> >On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
> >> use Foo; # from above, exports &bar is MMD::Random
> >> multi sub bar {...}
> >>
> >>Does this generate an error, since one could expect this particu
Leopold Toetsch wrote:
Rod Adams <[EMAIL PROTECTED]> wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short
David Storrs wrote:
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
There lingers the case of:
use Foo; # from above, exports &bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular &bar
to be Manhattan? Or does it assume Ran
[EMAIL PROTECTED] wrote:
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{"foo"} --> MultiSub{"foo_A_B" => Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Uh
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
> There lingers the case of:
>
>use Foo; # from above, exports &bar is MMD::Random
>
>multi sub bar {...}
>
> Does this generate an error, since one could expect this particular &bar
> to be Manhattan? Or does it assume Rando
Rod Adams <[EMAIL PROTECTED]> wrote:
> It seems to me that there are several advantages to making a group of
> multi with the same short name a single object, of type
> MultiSub|MultiMethod, which internally holds references to the all the
> various routines that share that short name.
Discussion
[EMAIL PROTECTED] wrote:
It would behave like a tied sub (or method), with a .dispatch method
to decide which of the contained routines should be called this
particular time. Manhattan would be the default. However, one can
override the dispatch logic; implementing Luke's Patterns idea, for
exa
Larry Wall wrote:
On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote:
: I was thinking more along the lines of :
:
:use MMD::Pattern;
:
:our &func is MMD::Pattern;
:
:multi func (...) {...}
:multi func (... ...) {...}
:multi func (... ... ...) {...}
:
:multi func2
On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote:
: I was thinking more along the lines of :
:
:use MMD::Pattern;
:
:our &func is MMD::Pattern;
:
:multi func (...) {...}
:multi func (... ...) {...}
:multi func (... ... ...) {...}
:
:multi func2 (...) {...}
:
Luke Palmer wrote:
Keep in mind that the two following definitions are equivalent:
class A { method foo () {...} }
multi sub foo (A $a) {...}
Except for attribute access, I think.
For public attrs the accessor is not used and private ones are available:
class A
{
has $.pub = "pub";
ha
Rod Adams writes:
> I wasn't intending it to be junctive. I was just noting that you needed
> separate holders for subs and methods, since you shouldn't be able to
> stuff a method into a multi sub.
Keep in mind that the two following definitions are equivalent:
class A { method foo () {...
Thomas Sandlaß wrote:
Rod Adams wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all
the various routines that share that short name.
It doesn't hav
Rod Adams wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
It doesn't have to be junctive becaus
21 matches
Mail list logo
