view release on metacpan or  search on metacpan

lib/Aspect.pm  view on Meta::CPAN

  around {
    print "Starting recursive child search\n";
    $_->proceed;
    print "Finished recursive child search\n";
  } call 'Person::find_child' & highest;
  
  # Run Advice only during the current lexical scope
  SCOPE: {
      my $hook = before {
          print "About to call create\n";
      } call 'Person::create';
      Person->create('Bob'); # Advice will run
  }
  Person->create('Tom'); # Advice won't run
  
  # Use a pre-packaged collection "Aspect" of Advice rules to change a class
  aspect Singleton => 'Foo::new';
  
  # Define debugger breakpoints with high precision and conditionality
  aspect Breakpoint => call qr/^Foo::.+::Bar::when_/ & wantscalar & highest;

=head1 DESCRIPTION

=head2 What is Aspect-Oriented Programming?

Aspect-Oriented Programming (AOP) is a programming paradigm which aims to
increase modularity by allowing the separation of "cross-cutting "concerns.

It includes programming methods and tools that support the modularization of
concerns at the level of the source code, while "aspect-oriented software
development" refers to a whole engineering discipline.

Aspect-Oriented Programming (AOP) allows you to modularise code for issues that
would otherwise be spread across many parts of a program and be problematic to
both implement and maintain.

Logging exemplifies a crosscutting concern because a logging strategy
necessarily affects every logged part of the system. Logging thereby "crosscuts"
all logged classes and methods.

Typically, an aspect is scattered or tangled as code, making it harder to
understand and maintain. It is scattered by virtue of the function (such as
logging) being spread over a number of unrelated functions that might use its
function, possibly in entirely unrelated systems

That means to change logging can require modifying all affected modules. Aspects
become tangled not only with the mainline function of the systems in which they
are expressed but also with each other. That means changing one concern entails
understanding all the tangled concerns or having some means by which the effect
of changes can be inferred.

Because Aspect-Oritented Programming moves this scattered code into a single
module which is loaded as a single unit, another major benefit of this method
is conditional compilation.

Features implemented via Aspects can be compiled and added to you program only
in certain situations, and because of this Aspects are useful when debugging
or testing large or complex programs.

Aspects can implement features necessary for correctness of programs such as
reactivity or synchronisation, and can be used to add checking assertions
to your or other people's modules.

They can cause code to emit useful side effects not considered by the original
author of a module, without changing the original function of the module.

And, if necessary (although not recommended), they can do various types of
"Monkey Patching", hijacking the functionality of some other module in an
unexpected (by the original author) way so that the module acts differently
when used in your program, when those changes might otherwise be dangerous or
if encountered by other programs.

Aspects can be used to implement space or time optimisations. One popular use
case of AOP is to add caching to a module or function that does not natively
implement caching itself.

For more details on Aspect-Oriented Programming in general,
L<http://en.wikipedia.org/wiki/Aspect-oriented_programming> and
L<http://www.aosd.net>.

=head2 About This Implementation

The Perl B<Aspect> module tries to closely follow the terminology of the basic
Java AspectJ project wherever possible and reasonable
(L<http://eclipse.org/aspectj>).

However due to the dynamic nature of the Perl language, several C<AspectJ>
features are useless for us: exception softening, mixin support, out-of-class
method declarations, annotations, and others.

Currently the Perl B<Aspect> module is focused exclusively on subroutine
matching and wrapping.

It allows you to select collections of subroutines and conditions using a
flexible pointcut language, and modify their behavior in any way you want.

In this regard it provides a similar set of functionality to the venerable
L<Hook::LexWrap>, but with much more precision and with much more control and
maintainability as the complexity of the problems you are solving increases.

In addition, where the Java implementation of Aspect-Oriented Programming is
limited to concepts expressable at compile time, the more fluid nature of Perl
means that the B<Aspect> module can weave in aspect code at run-time. Pointcuts
in Perl can also take advantage of run-time information and Perl-specific
features like closures to implement more sophisticated pointcuts than are
possible in Java.

This allows the Perl implementation of Aspect-Oriented Programming to be
stateful and adaptive in a way that Java cannot (although the added power can
come with a significant speed cost if not used carefully).

=head2 Terminology

One of the more opaque aspects (no pun intended) of Aspect-Oriented programming
is that it has an entire unique set of terms that can be confusing for people
learning to use the B<Aspect> module.

In this section, we will attempt to define all the major terms in a way that
will hopefully make sense to Perl programmers.

=head3 What is an Aspect?