> 
> I would be interested to see an example of how you would use augment and 
> inner with roles. I could never picture a way to do it in which it didn't 
> seem overly confusing, but I am always willing to admit to my own lack of 
> imagination :)
> 
> - Stevan
> 


Cool! I like imaginative.  I'll start with what I am actually doing - a fancy 
package installer.

package Installer::Role;

sub prepare{
  my $self = shift;
  $self->find_right_version;
  $self->make_other_common_things;
  inner;
  $self->signal_other_parts_of_the_system_and_stuff;
}

package Installer::WTF_OMG; #I just thought that was so funny yesterday!

augment prepare => sub {
   my $self = shift;
   $self->make_configuration_file;
};

package Installer::LittleApp;

augment prepare => sub{
    my $self = shift;
    $self->load_this_weird_db_the_little_app_is_using;
};

Now obviously, I could just have a CUSTOM_PREPARE or something that the role 
calls.  It's just that inner/augment seemed to be such a nice paradigm for 
this.  (I tested and verified that inner will not fail if no augment is present 
 - which is nice also.

One reason augment is so nice is code readability. With OO Inheritance, there 
is that constant frustration of hunting down where the actual implementation of 
the thing you are looking for lives.  

You start with some silly script you inherited that says, $foo->doit;  
You scroll up and find that you need to be looking in Foo::Bar
There is no doit in Foo/Bar.pm
You scroll up and find use base qw/Foo/;
You find doit there, which ever-so-helpfully looks like sub { shift->doitnow}...
You find doitnow in the parent, just to discover after hours of debugging that 
it was overridden in the child.
You consider whether quitting smoking was such a good idea after all...

Method modifiers really improve the situation for recovering addicts, you see?  
But none as much as augment/inner, as the parent  (or role) "lays out" exactly 
what you need to be looking for:  "There may be something custom in there!"


Reply via email to