Re: Why submethods

[Uri Guttman]

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:

  DC> But factoring method implementations out into a subroutines is
  DC> also extremely annoying, because a subroutine doesn't provide the
  DC> internal conveniences that a method does. In particular, it
  DC> doesn't have an invocant and so you can't call $.attrs or
  DC> &.methods. Instead you would have to pass the invocant to the
  DC> subroutine call as an argument and then call accessors and methods
  DC> explicitly through that argument.

  DC> So we need a mechanism that is externally (i.e. from a class
  DC> interface point-of-view) a subroutine, but internally has the
  DC> features of a method (i.e. has an invocant). Since it's externally
  DC> sub-like but internally method-like, we call this useful construct
  DC> a submethod.

so it sounds like to me these are methods private to this class. they
can't found by any other class (via inheritance). so what is the
external sub interface for? we can see the need for private worker
methods and even p5 has a convention of marking such subs with a leading
_. 


uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: Why submethods

[Sam Vilain]

On Sat, 2005-10-29 at 17:30 -0400, Stevan Little wrote:
> However, it could also be that the creator of Foo did not intend for  
> subclasses to be able to "Just Work", and that the whole idea of Foo  
> is to do a "Template Method" style pattern in which subclasses must  
> implement the &help_process_data submethod in order for things to  
> work. This is an entirely valid usage for a submethod, and in fact, I  
> think it is an excellent way for implementing the "Template Method"  
> pattern.

Hmm.  I think I much prefer;

  method you_must_implement { ... }

or a trait, perhaps

  method you_must_implement is required;

I think that methods disappearing out of scope in subclasses is just
Nasty And Wrong™, for the exact reason Luke outlined.  Side-effects like
that are just asking for trouble IMHO.

> It is also possible that we could bring over the role idea of  
> "required methods" and have the same basic principle relate to  
> classes and submethods. If marked as such, a submethod is required to  
> be implemented by a subclass, or class composition fails.
> I think that could be a useful feature which would allow very safe
> re-use along those lines.

Good point, which is why the "is required" as above would be better.

It seems to me that there's an awful lot of specification going into
these varied types of methods.

  Method Type  Purpose   DispatchVisibility
 ---|--|---|
  $.method()|  external API|  MMD  |  all
  $.submethod() |  refactoring |  package  |  single
  $:private()   |  internal API|  package  |  single

I must admit I also fail to see the difference between submethods and
private methods.  And what do I use for methods that I don't want to
make visible to "the world"?

Perhaps a more useful definition might be that submethods are only
available on $?SELF (and are still subject to normal dispatch).

Sam.