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