Trey Harris wrote:
It sounds like the assumption thus far has been that the existance of
roles imply that abstract classes are disallowed, so you'd write:
role Dog { method bark { ... } #[ ... ] }
class Pug does Dog { method bark { .vocalize($.barkNoise) } }
S12 says: "Classes are primarily for instance management, not code reuse.
Consider using C<roles> when you simply want to factor out
common code."
To me, "instance management" means "the package can create, build, and
destroy objects" - not "the package initializes and cleans up
attributes". A 'class' that is forbidden from creating, building, and
destroying objects isn't a class; it's a role. In fact, you can think
of 'role' as being shorthand for 'abstract class' - after all, the
only difference between a concrete class and an abstract class is that
the former must implement everything and can manage instances, while
the latter cannot manage instances but doesn't have to implement
everything.
-snip-
In Perl 6, the abstract SystemMonitor could be a role, and a concrete
ScriptedMonitor could be a class that does SystemMonitor, but it's not at
all clear to me what HardwareMonitor would be, since classes can't be
abstract and roles can't inherit from classes.
S12 says:
*> A role is allowed to declare an additional inheritance for its
*> class when that is considered an implementation detail:
*>
*> role Pet {
*> is Friend;
*> }
So:
role SystemMonitor { ... }
class CPUMonitor does SystemMonitor { ... }
class DiskMonitor does SystemMonitor { ... }
class ScriptedMonitor does SystemMonitor { ... }
role HardwareMonitor is ScriptedMonitor { ... }
class FanMonitor does HardwareMonitor { ... }
class TempMonitor does HardwareMonitor { ... }
class PowerSupplyMonitor does HardwareMonitor { ... }
# and so on
is perfectly valid, and is shorthand for
role SystemMonitor { ... }
role HardwareMonitor { ... }
class CPUMonitor does SystemMonitor { ... }
class DiskMonitor does SystemMonitor { ... }
class ScriptedMonitor does SystemMonitor { ... }
class FanMonitor is ScriptedMonitor does HardwareMonitor { ... }
class TempMonitor is ScriptedMonitor does HardwareMonitor { ... }
class PowerSupplyMonitor is ScriptedMonitor does HardwareMonitor { ... }
# and so on
ISTR that it's also possible to treat a class as if it were a role
(e.g., "does classname" is valid, both as a statement in another role
or class and as an expression used to test the truth of the claim),
although I can't seem to find documentation for this at the moment.
--
Jonathan "Dataweaver" Lang
