On Thu, Oct 13, 2005 at 05:42:31 +1000, Damian Conway wrote:
> Luke wrote:
>
> >Okay, I seriously have to see an example of a submethod in use.
>
> class Driver::Qualified {
> method drive {
> print "Brrrm brrrm!"
> }
> }
>
> class Driver::Disqualified is Driver {
> submethod drive {
> die .name(), " not allowed to drive"
> }
> }
>
> class Driver::Requalified is Driver::Disqualified {}This is not obvious that the behavior is modified, and it makes other subclasses, like Driver::Disqualified::Drunk and Driver::Disqualified::Suicidal causes the above design choice to make you either update Driver::Requalified and Driver::Disqualified to regular methods, or duplicate code in Driver::Disqualified::*. That much aside, this is not a real world example. Can you try to think of one that really applies? Looking at my past $work projects I can't think of a single instance where submethods would help me code better. On the other hand roles & mixin inheritence, private attributes that don't conflict with other private attributes of the same name, better polymorphism, better introspection, and a metamodel could have helped a lot in many places. This has even more implications with closed classes to which you don't have source level access, and if this can happen it will happen - i'm pretty sure that some commercial database vendors would release closed source DBDs, for example. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM: neeyah!
pgpb15yuOsYCY.pgp
Description: PGP signature
