view release on metacpan or  search on metacpan

README  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;

DESCRIPTION
  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,
    <http://en.wikipedia.org/wiki/Aspect-oriented_programming> and
    <http://www.aosd.net>.

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

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

    Currently the Perl 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 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 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).

  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 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.