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
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
> "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
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
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
In his use.perl.org journal, Luke wrote:
> To be fair, Damian responded to my query, but he didn't answer my
> question. He gave more an example of how submethods are used, rather
> than why they are used.
Subroutines are useful inside classes, for factoring class-specific
implementation detail
