Provided by: libasa-perl_1.04-2_all bug

NAME

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

VERSION

       version 1.04

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

SEE ALSO

       <http://ali.as/>

SUPPORT

       Bugs may be submitted through the RT bug tracker
       <https://rt.cpan.org/Public/Dist/Display.html?Name=asa> (or bug-asa@rt.cpan.org
       <mailto:bug-asa@rt.cpan.org>).

AUTHOR

       Adam Kennedy, <adamk@cpan.org>

CONTRIBUTORS

       •   Adam Kennedy <adam@ali.as>

       •   Karen Etheridge <ether@cpan.org>

COPYRIGHT AND LICENSE

       This software is copyright (c) 2006 by Adam Kennedy.

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