Re: Multisubs and multimethods: what's the difference?
Stevan Little wrote: > Jonathan Lang wrote: > > Steven Little wrote: > > > $object does unattached_method; > > > ^Object does unattached_method; > > > > (Wouldn't that be "^$object does unattached_method;"?) > > No, I am attaching the method (well role really) to the class ^Object. > There is no such thing as ^$object IIRC. Upon a closer reading of S12, it appears that both are valid: "prefix:<^>" is syntactic sugar for method meta, and it returns the object's metaclass; thus, ^$object is equivalent to $object.meta. I'm still in the process of trying to grasp the concept of prototype objects; but it appears that ^Object is the same as ^$object. -- Jonathan Lang
Re: Multisubs and multimethods: what's the difference?
On 3/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Stevan Little wrote:
> > Jonathan Lang wrote:
> > > Can subs be declared within classes? Can methods be declared without
> > > classes?
> >
> > I would say "yes".
> >
> > Having subs inside classes makes creating small utility functions
> > easier. You could also use private methods for this, but if I dont
> > need to pass the object instance, why make me? I will say that I think
> > this distinction will be difficult at first for people steeped in Perl
> > 5 OO.
>
> Sounds reasonable. I'm curious: can anyone think of any _public_ uses
> for subs that are declared within classes?
Same uses they would have in Perl 5 I would guess, but I don't usually
do that in Perl 5 so I am hard pressed to come up with a specific
example.
> > Having methods outside of classes is less useful, and most of it's
> > uses are pretty esoteric, however I see no good reason not to allow it
> > (especially anon methods, as they are critical to being able to do
> > some of the cooler meta-model stuff).
>
> OK; so declaring a method outside of a class could let you define one
> method that applies to a wide range of classes, without having to
> declare a separate method for each class. I can see how that might
> come in handy.
>
> > A method probably cannot be invoked without first being attached to a
> > class somehow because it needs something to SMD off of.
>
> Why not? IIRC, SMD differs from MMD dispatch-wise in terms of how
> many of its parameters are used (one instead of all). If I were to
> define "method foo(Complex $bar)" and "multi foo(Num $bar)", I could
> then say "foo i" and expect to be dispatched to the method; whereas
> "foo e" would dispatch to the sub. Likewise, "i.foo" would dispatch
> to the method, while "e.foo" would die due to improper syntax.
I suppose this is all in the details of how we do SMD. It's things
like this that make me think that SMD is just a special case of MMD,
but I think that dead horse has already been beaten here, and I am not
in the mood to reanimate it really.
> At least, that's how I see it. What's the official position on what
> happens when you mix SMD, MMD, and/or no dispatch versions of a
> routine?
>
> > But you could
> > almost look at a bare (and named) method as a mini-role, so that:
> >
> > method unattached_method ($::CLASS $self:) { ... }
> >
> > is essentially equivalent to this:
> >
> > role unattached_method {
> > method unattached_method ($::CLASS $self:) { ... }
> > }
> >
> > which of course brings up the possibility of this syntax:
> >
> > $object does unattached_method;
> > ^Object does unattached_method;
>
> (Wouldn't that be "^$object does unattached_method;"?)
No, I am attaching the method (well role really) to the class ^Object.
There is no such thing as ^$object IIRC.
> > as a means of adding methods to a class or object (ruby-style
> > singleton methods).
>
> Hmm: I don't see a need for this with respect to adding methods to a
> class; just declare a method that takes a first parameter of the
> appropriate class. OTOH, TIMTOWTDI: I could see arguments for
> allowing "^$object does method foo() { ... }" as well. OTGH, adding
> methods to an individual object would pretty much require the use of
> an anonymous role. So the idea that "does" wraps bare methods in an
> anonymous role does seem to have merit.
exactly the conclusions I came too as well, which is one of the reason
why I really like hanging out on this mailing list
:)
- Stevan
Fwd: Multisubs and multimethods: what's the difference?
Stevan Little wrote:
> Jonathan Lang wrote:
> > Can subs be declared within classes? Can methods be declared without
> > classes?
>
> I would say "yes".
>
> Having subs inside classes makes creating small utility functions
> easier. You could also use private methods for this, but if I dont
> need to pass the object instance, why make me? I will say that I think
> this distinction will be difficult at first for people steeped in Perl
> 5 OO.
Sounds reasonable. I'm curious: can anyone think of any _public_ uses
for subs that are declared within classes?
> Having methods outside of classes is less useful, and most of it's
> uses are pretty esoteric, however I see no good reason not to allow it
> (especially anon methods, as they are critical to being able to do
> some of the cooler meta-model stuff).
OK; so declaring a method outside of a class could let you define one
method that applies to a wide range of classes, without having to
declare a separate method for each class. I can see how that might
come in handy.
> A method probably cannot be invoked without first being attached to a
> class somehow because it needs something to SMD off of.
Why not? IIRC, SMD differs from MMD dispatch-wise in terms of how
many of its parameters are used (one instead of all). If I were to
define "method foo(Complex $bar)" and "multi foo(Num $bar)", I could
then say "foo i" and expect to be dispatched to the method; whereas
"foo e" would dispatch to the sub. Likewise, "i.foo" would dispatch
to the method, while "e.foo" would die due to improper syntax.
At least, that's how I see it. What's the official position on what
happens when you mix SMD, MMD, and/or no dispatch versions of a
routine?
> But you could
> almost look at a bare (and named) method as a mini-role, so that:
>
> method unattached_method ($::CLASS $self:) { ... }
>
> is essentially equivalent to this:
>
> role unattached_method {
> method unattached_method ($::CLASS $self:) { ... }
> }
>
> which of course brings up the possibility of this syntax:
>
> $object does unattached_method;
> ^Object does unattached_method;
(Wouldn't that be "^$object does unattached_method;"?)
> as a means of adding methods to a class or object (ruby-style
> singleton methods).
Hmm: I don't see a need for this with respect to adding methods to a
class; just declare a method that takes a first parameter of the
appropriate class. OTOH, TIMTOWTDI: I could see arguments for
allowing "^$object does method foo() { ... }" as well. OTGH, adding
methods to an individual object would pretty much require the use of
an anonymous role. So the idea that "does" wraps bare methods in an
anonymous role does seem to have merit.
--
Jonathan Lang
Re: Multisubs and multimethods: what's the difference?
On 3/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Can subs be declared within classes? Can methods be declared without
> classes? If the answers to both of these questions are "no", then it
> occurs to me that you _could_ unify the two under a single name, using
> the class boundary as the distinguishing factor (e.g., a method is
> merely a sub declared within a class). If the answer to either is
> "yes", I'd be curious to know how it would work.
I would say "yes".
Having subs inside classes makes creating small utility functions
easier. You could also use private methods for this, but if I dont
need to pass the object instance, why make me? I will say that I think
this distinction will be difficult at first for people steeped in Perl
5 OO.
Having methods outside of classes is less useful, and most of it's
uses are pretty esoteric, however I see no good reason not to allow it
(especially anon methods, as they are critical to being able to do
some of the cooler meta-model stuff).
A method probably cannot be invoked without first being attached to a
class somehow because it needs something to SMD off of. But you could
almost look at a bare (and named) method as a mini-role, so that:
method unattached_method ($::CLASS $self:) { ... }
is essentially equivalent to this:
role unattached_method {
method unattached_method ($::CLASS $self:) { ... }
}
which of course brings up the possibility of this syntax:
$object does unattached_method;
^Object does unattached_method;
as a means of adding methods to a class or object (ruby-style
singleton methods).
Of course, this could also just be my not-quite-caffinated-enough
brain talking too.
Stevan
Re: Separate compilation and compile-time things
On Thu, Mar 02, 2006 at 15:13:07 +0200, Zohar Kelrich wrote:
> We were discussing some confusing macro behaviours, when we came upon this
> curious thing. This code is really simple in p5, as it doesn't really have
> separate compilation, but in p6, the modules can be pre- compiled or cached.
> 8<--
> module ImportHeadache;
> my $m;
>
> sub import() {
> $m++;
> }
>
> sub report is export { $m };
>
> sub deport {...}
> #-- Meanwhile, elsewhere!
> module Elsewhere;
> use ImportHeadache; # I'm calling import at Elsewhere's compile time!
>
> #-- Meanwhile, another elsewhere!
> module Elsewhere2;
> use ImportHeadache; # I'm calling import at Elsewhere2's compile time!
>
> #-- Main program
> use v6;
> use Elsewhere;
> use Elsewhere2;
> use ImportHeadache;
>
> say report; # What should I say?
>
> -->8
> The result is, of course, (1..3).pick(), depending on whether the modules
> were compiled by the same compiler instance at the same time.
Perl 6 is specced such that it's always separate compilation, so
this should probably always be 0, unless you're tying the value to
disk.
The way it's handled:
$m is reallocated every time a module is used, and thrown away after
it finished compiling.
Then the resulting code will be linked, after $m was garbage
collected. This code can be relinked as many times as we want.
> The problem seems to be that we have statefulness that we expect to survive
> compilation boundaries.
Well, Perl 5 didn't have such boundries =)
All statefulness in Perl 6 is not saved. Values and code are
dumoped, and will be loaded on every link. This means that this does
not get saved back to disk. This also means that linkage could be
cached.
> So, should each compilation unit get a fresh environment? Or should this
> simply work like I think it currently does, and just hopefully not bite
> people
> too often? Should doing what this is trying to do be possible in a
> different, longer-huffmanized way?
I think separate compilation is more consistent - it allows much
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me tips over a cow: neeyah!!
pgpvcXIoJdS3m.pgp
Description: PGP signature
Re: Separate compilation and compile-time things
One way to think of your macro example (instead of the ->import one, which is harder to define, i think): Every time you use a module it's used by the compiler, and by the emitted code. The compiler loads the macros, the emitted code loads the non-macro stuff. Since the clsoure is created in the compiler's runtime this is slightly consistent ;-) -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgpmGMthxUDLd.pgp Description: PGP signature
Separate compilation and compile-time things
We were discussing some confusing macro behaviours, when we came upon
this curious thing. This code is really simple in p5, as it doesn't
really have separate compilation, but in p6, the modules can be pre-
compiled or cached.
8<--
module ImportHeadache;
my $m;
sub import() {
$m++;
}
sub report is export { $m };
sub deport {...}
#-- Meanwhile, elsewhere!
module Elsewhere;
use ImportHeadache; # I'm calling import at Elsewhere's compile time!
#-- Meanwhile, another elsewhere!
module Elsewhere2;
use ImportHeadache; # I'm calling import at Elsewhere2's compile time!
#-- Main program
use v6;
use Elsewhere;
use Elsewhere2;
use ImportHeadache;
say report; # What should I say?
-->8
The result is, of course, (1..3).pick(), depending on whether the
modules were compiled by the same compiler instance at the same time.
Separate compilation may push this number down.
This is deeply weird.
The same thing can happen with macros closing over a value.
(Demonstration is left as an exercise for the weeder :D)
The problem seems to be that we have statefulness that we expect to
survive compilation boundaries.
So, should each compilation unit get a fresh environment? Or should
this simply work like I think it currently does, and just hopefully
not bite people too often? Should doing what this is trying to do be
possible in a different, longer-huffmanized way?
--
Zohar
Re: Multisubs and multimethods: what's the difference?
Larry Wall wrote: > A multi sub presents only an MMD interface, while a multi method presents > both MMD and SMD interfaces. In this case, there's not much point in the > SMD inteface since .. used as infix is always going to call the MMD interface. So: multi method : MMD and SMD multi sub: MMD only method: SMD only sub: no dispatching right? And just so that it's clear: when you talk about the SMD interface, you're talking about being able to say "$var.foo" instead of "foo $var", right? Whereas MMD doesn't have any special calling syntax. Otherwise, the only difference between MMD and SMD would be the number of arguments that are used for dispatching purposes (all of them vs. just the first one). Can subs be declared within classes? Can methods be declared without classes? If the answers to both of these questions are "no", then it occurs to me that you _could_ unify the two under a single name, using the class boundary as the distinguishing factor (e.g., a method is merely a sub declared within a class). If the answer to either is "yes", I'd be curious to know how it would work. -- Jonathan "Dataweaver" Lang
