NAME
    asa - Lets your class/object say it works like something else

SYNOPSIS
      #########################################
      # Your Code
  
      package My::WereDuck;
  
      use base 'My::Lycanthrope';
      use asa  'Duck';
  
      sub quack {
          return "Hi! errr... Quack!";
      }
  
      ################################################
      # Their Code
  
      sub strangle {
          my $duck = shift;
          unless ( $duck->isa('Duck') ) {
              die "We only strangle ducks";
          }
          print "Farmer Joe wrings the duck's neck\n";
          print "Said the duck, '" . $duck->quack . "'\n";
          print "We ate well that night.\n";
      }

DESCRIPTION
    Perl 5 doesn't natively support Java-style interfaces, and it doesn't
    support Perl 6 style roles either.

    You can get both of these things in half a dozen different ways via
    various CPAN modules, but they usually require that you buy into "their
    way" of implementing your code.

    Other have turned to "duck typing".

    This is, for the most part, a fairly naive check that says "can you do
    this method", under the "if it looks like a duck, and quacks like a
    duck, then it must be a duck".

    It assumes that if you have a "->quack" method, then they will treat you
    as a duck, because doing things like adding "Duck" to your @ISA array
    means you are also forced to take their implementation.

    There is, of course, a better way.

    For better or worse, Perl's "->isa" functionality to determine if
    something is or is not a particular class/object is defined as a method,
    not a function, and so that means that as well as adding something to
    you @ISA array, so that Perl's "UNIVERSAL::isa" method can work with it,
    you are also allowed to simply overload your own "isa" method and answer
    directly whether or not you are something.

    The simplest form of the idiom looks like this.

      sub isa {
          return 1 if $_[1] eq 'Duck';
          shift->SUPER::isa(@_);
      }

    This reads "Check my type as normal, but if anyone wants to know if I'm
    a duck, then tell them yes".

    Now, there are a few people that have argued that this is "lying" about
    your class, but this argument is based on the idea that @ISA is somehow
    more "real" than using the method directly.

    It also assumes that what you advertise you implement needs to be in
    sync with the method resolution for any given function. But in the best
    and cleanest implementation of code, the API is orthogonal (although
    most often related) to the implementation.

    And although @ISA is about implementation and API, overloading "isa" to
    let you change your API is not at all bad when seen in this light.

  What does asa.pm do?
    Much as base provides convenient syntactic sugar for loading your parent
    class and setting @ISA, this pragma will provide convenient syntactic
    sugar for creating your own custom overloaded isa functions.

    Beyond just the idiom above, it implements various workarounds for some
    edge cases, so you don't have to, and allows clear seperation of
    concerns.

    You should just be able to use it, and if something ever goes wrong,
    then it's my fault, and I'll fix it.

  What doesn't asa.pm do?
    In Perl, highly robust introspection is really hard. Which is why most
    modules that provide some level of interface functionality require you
    to explicitly define them in multiple classes, and start to tread on
    your toes.

    This class does not do any strict enforcement of interfaces. 90% of the
    time, what you want to do, and the methods you need to implement, are
    going to be pretty obvious, so it's your fault if you don't provide
    them.

    But at least this way, you can implement them however you like, and
    "asa" will just take care of the details of safely telling everyone else
    you are a duck :)

  What if a Duck method clashes with a My::Package method?
    Unlike Perl 6, which implements a concept called "multi-methods", Perl 5
    does not have a native approach to solving the problem of "API
    collision".

    Originally from the Java/C++ world, the problem of overcoming language
    API limitations can be done through the use of one of several "design
    patterns".

    For you, the victim of API collision, you might be interested in the
    "Adapter" pattern.

    For more information on implementing the Adapter pattern in Perl, see
    Class::Adapter, which provides a veritable toolkit for creating an
    implementation of the Adapter pattern which can solve your problem.

SUPPORT
    Bugs should be always be reported via the CPAN bug tracker at

    <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=asa>

    For other issues, or commercial enhancement or support, contact the
    author.

AUTHORS
    Adam Kennedy <cpan@ali.as<

SEE ALSO
    base, <http://ali.as/>

COPYRIGHT
    Copyright (c) 2006 Adam Kennedy. All rights reserved.

    This program is free software; you can redistribute it and/or modify it
    under the same terms as Perl itself.

    The full text of the license can be found in the LICENSE file included
    with this module.