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
