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
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
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
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 details
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 this
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) {
