Re: Why submethods

2005-11-03 Thread TSa
HaloO, Luke Palmer wrote: On 10/29/05, Damian Conway <[EMAIL PROTECTED]> wrote: So we need a mechanism that is externally (i.e. from a class interface point-of-view) a subroutine, but internally has the features of a method (i.e. has an invocant). Since it's externally sub-like but internally

Re: Why submethods

2005-10-30 Thread 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_pro

Re: Why submethods

2005-10-30 Thread 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

Re: Why submethods

2005-10-29 Thread Stevan Little
Luke, On Oct 29, 2005, at 3:42 PM, Luke Palmer wrote: Another thing that scares me with the "utility sub" point of view follows: class Foo { method process_data($data) { $.help_process_data($data); } submethod help_process_data($data) { $dat

Re: Why submethods

2005-10-29 Thread Luke Palmer
On 10/29/05, Damian Conway <[EMAIL PROTECTED]> wrote: > So we need a mechanism that is externally (i.e. from a class interface > point-of-view) a subroutine, but internally has the features of a method (i.e. > has an invocant). Since it's externally sub-like but internally method-like, > we call th