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