Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Re^4: Private method variations

by TimToady (Parson)
on Mar 02, 2004 at 00:57 UTC ( #333130=note: print w/ replies, xml ) Need Help??


in reply to Re^4: Private method variations
in thread Private method variations

Is this in addition to the submethods mentioned in Apocalypse 6, which seem to solve the same sort of issues?
Yes. Submethods are for private implementation of a public interface. They're really ordinary public methods that just happen to say "Don't inherit from me, keep looking up the tree for a real method."

By contrast, a private method cannot be called from outside the class. It is, in fact, just a subroutine that the class declares with a syntax resembling method declaration, and that it can call with a syntax resembling ordinary method call, but there's no dispatcher behind the scenes trying to decide which class to dispatch to. It absolutely calls into the current class. If you use the ordinary dot instead, it absolutely goes to the ordinary dispatcher, which totally ignores all private methods, even in your own class.


Comment on Re: Re^4: Private method variations
Re^6: Private method variations
by adrianh (Chancellor) on Mar 02, 2004 at 01:40 UTC

    So why would I ever prefer to use a submethod over a private method? This might just be my brain at 1:30am but I can't see a use case that submethod fits better than a private method.

    Any chance of enlightenment or should I just wait for A12/E12 :-)

      Private methods are completely invisible outside of a class, so they cannot participate in the public interface. Submethods can be called from outside a class just like ordinary methods. The only way that submethods are different from methods is that the dispatcher ignores them unless there's an exact match on the class (either because that's the class of the object in question, or because the class was requested as part of, say, a SUPER::.)

      For instance, if you write a constructor such that it can be inherited, then you should declare it a method. But if there are implementation dependencies in your constructor that would make it a bad idea to inherit, then you should declare it a submethod. It's not a private method--you can still call it from outside the class. But any class deriving from your class had better arrange for its own constructor, unless some other class in the tree provides an inheritable constructor.

      In particular, initialization routines that work on your particular set of attributes should submethods. It makes no sense to virtualize such a utility routine, because if you do hierarchical construction and destruction (as Perl 6 will), you'd just end up initializing the same attributes more than once if someone else uses your routine on their class that derives from your class. On the other hand, the routine needs to be callable from outside the class, or your child classes can't walk up the class tree to do hierarchical initialization.

      On the gripping hand, classes with a standardized list of attributes can inherit a standard initialization routine that is metadata driven, and hence class independent. But it's probably slower than if you hard-wired it for your class. Submethods allow both implementation inheritance and implementation hiding under the same public interface.

        Submethods allow both implementation inheritance and implementation hiding under the same public interface.

        Ah. I see. Nice. Thanks.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://333130]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (8)
As of 2014-09-19 22:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (151 votes), past polls