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
