In a message dated Thu, 28 Sep 2006, Jonathan Lang writes:
while roles can be abstract, classes and packages should not be.
Really? I think I need to let that sink in and percolate a bit.
I'm rather fond of creating abstract superclasses to factor out common
object-management code. I have many classes in Perl 5 with code like
this:
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
if ($class eq __PACKAGE__) {
croak "Attempt to instantiate abstract class $class";
}
# Proceed with common object instantiation
}
and then the concrete subclasses either don't define &new at all or do
their own subclass-specific initializations and call NEXT to get the
common initializations. I've been thinking that a role is not the proper
place for this sort of code, as it is tightly coupled to implementation,
and my understanding of the gestalt of roles is that they should be
loosely coupled to their users' implementations.
But if only a role can be abstract, I guess I'd have to use a role (or
fall back to the Perl 5-ism above and check my .HOW and throw a runtime
exception).
If you define a BUILD in a role, will it be called when an object of a
class that does the role is instantiated, as part of the .new BUILD walk?
Trey
