.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{
.    if \nF \{
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
.    \" fudge factors for nroff and troff
.if n \{\
.    ds #H 0
.    ds #V .8m
.    ds #F .3m
.    ds #[ \f1
.    ds #] \fP
.\}
.if t \{\
.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
.    ds #V .6m
.    ds #F 0
.    ds #[ \&
.    ds #] \&
.\}
.    \" simple accents for nroff and troff
.if n \{\
.    ds ' \&
.    ds ` \&
.    ds ^ \&
.    ds , \&
.    ds ~ ~
.    ds /
.\}
.if t \{\
.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
.    \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
.    \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
.    \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
.    ds : e
.    ds 8 ss
.    ds o a
.    ds d- d\h'-1'\(ga
.    ds D- D\h'-1'\(hy
.    ds th \o'bp'
.    ds Th \o'LP'
.    ds ae ae
.    ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "Class::Std 3"
.TH Class::Std 3 "2016-08-24" "perl v5.16.3" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
Class::Std \- Support for creating standard "inside\-out" classes
.SH "VERSION"
.IX Header "VERSION"
This document describes Class::Std version 0.013
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 2
\&    package MyClass;
\&    use Class::Std;
\&
\&    # Create storage for object attributes...
\&    my %name : ATTR;
\&    my %rank : ATTR;
\&    my %snum : ATTR;
\&
\&    my %public_data : ATTR;
\&
\&    # Handle initialization of objects of this class...
\&    sub BUILD {
\&        my ($self, $obj_ID, $arg_ref) = @_;
\&
\&        $name{$obj_ID} = check_name( $arg_ref\->{name} );
\&        $rank{$obj_ID} = check_rank( $arg_ref\->{rank} );
\&        $snum{$obj_ID} = _gen_uniq_serial_num();
\&    }
\&
\&    # Handle cleanup of objects of this class...
\&    sub DEMOLISH {
\&        my ($self, $obj_ID) = @_;
\&
\&        _recycle_serial_num( $snum{$obj_ID} );
\&    }
\&
\&    # Handle unknown method calls...
\&    sub AUTOMETHOD {
\&        my ($self, $obj_ID, @other_args) = @_;
\&
\&        # Return any public data...
\&        if ( m/\eA get_(.*)/ ) {  # Method name passed in $_
\&            my $get_what = $1;
\&            return sub {
\&                return $public_data{$obj_ID}{$get_what};
\&            }
\&        }
\&
\&        warn "Can\*(Aqt call $method_name on ", ref $self, " object";
\&
\&        return;   # The call is declined by not returning a sub ref
\&    }
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
This module provides tools that help to implement the \*(L"inside out object\*(R"
class structure in a convenient and standard way.
.PP
\&\fIPortions of the following code and documentation from \*(L"Perl Best Practices\*(R"
copyright (c) 2005 by O'Reilly Media, Inc. and reprinted with permission.\fR
.SS "Introduction"
.IX Subsection "Introduction"
Most programmers who use Perl's object-oriented features construct their
objects by blessing a hash. But, in doing so, they undermine the
robustness of the \s-1OO\s0 approach. Hash-based objects are unencapsulated:
their entries are open for the world to access and modify.
.PP
Objects without effective encapsulation are vulnerable. Instead of
politely respecting their public interface, some clever client coder
inevitably will realize that it's marginally faster to interact directly
with the underlying implementation, pulling out attribute values
directly from the hash of an object:
.PP
.Vb 3
\&    for my $file ( get_file_objs() ) {
\&        print $file\->{name}, "\en";
\&    }
.Ve
.PP
instead of using the official interface:
.PP
.Vb 3
\&    for my $file ( get_file_objs() ) {
\&        print $file\->get_name(), "\en";
\&    }
.Ve
.PP
From the moment someone does that, your class is no longer cleanly
decoupled from the code that uses it. You can't be sure that any bugs in
your class are actually caused by the internals of your class, and not
the result of some kind of monkeying by the client code. And to make
matters worse, now you can't ever change those internals without the
risk of breaking some other part of the system.
.PP
There is a simple, convenient, and utterly secure way to prevent client
code from accessing the internals of the objects you provide. Happily,
that approach also guards against misspelling attribute names (a common
error in hash-based classes), as well as being just as fast as\*(--and
often more memory-efficient than\*(--ordinary hash-based objects.
.PP
That approach is referred to by various names\*(--flyweight scalars,
warehoused attributes, inverted indices\*(--but most commonly it's known
as: inside-out objects. Consider the following class definitions:
.PP
.Vb 5
\&    package File::Hierarchy;
\&    {
\&        # Objects of this class have the following attributes...
\&        my %root_of;   # The root directory of the file hierarchy
\&        my %files_of;  # Array storing object for each file in root directory
\&        
\&        # Constructor takes path of file system root directory...
\&        sub new {
\&            my ($class, $root) = @_;
\&        
\&            # Bless a scalar to instantiate the new object...
\&            my $new_object = bless \edo{my $anon_scalar}, $class;
\&        
\&            # Initialize the object\*(Aqs "root" attribute...
\&            $root_of{ident $new_object} = $root;
\&        
\&            return $new_object;
\&        }
\&        
\&        # Retrieve files from root directory...
\&        sub get_files {
\&            my ($self) = @_;
\&        
\&            # Load up the "files" attribute, if necessary...
\&            if (!exists $files_of{ident $self}) {
\&                $files_of{ident $self} 
\&                    = File::System\->list_files($root_of{ident $self});
\&            }
\&        
\&            # Flatten the "files" attribute\*(Aqs array to produce a file list...
\&            return @{ $files_of{ident $self} };
\&        }
\&    }
\&
\&    package File::Hierarchy::File;
\&    {    
\&        # Objects of this class have the following attributes...
\&        my %name_of;  # the name of the file
\&        
\&        # Constructor takes name of file...
\&        sub new {
\&            my ($class, $filename) = @_;
\&        
\&            # Bless a scalar to instantiate the new object...
\&            my $new_object = bless \edo{my $anon_scalar}, $class;
\&        
\&            # Initialize the object\*(Aqs "name" attribute...
\&            $name_of{ident $new_object} = $filename;
\&        
\&            return $new_object;
\&        }
\&        
\&        # Retrieve name of file...
\&        sub get_name {
\&            my ($self) = @_;
\&        
\&            return $name_of{ident $self};
\&        }
\&    }
.Ve
.PP
Unlike a hash-based class, each of these inside-out class is specified
inside a surrounding code block:
.PP
.Vb 4
\&    package File::Hierarchy;
\&    {
\&        # [Class specification here]
\&    }
\&
\&    package File::Hierarchy::File;
\&    {
\&        # [Class specification here]
\&    }
.Ve
.PP
That block is vital, because it creates a limited scope, to which any
lexical variables that are declared as part of the class will
automatically be restricted.
.PP
The next difference between the two versions of the classes is that each 
attribute of \fIall\fR the objects in the class is now stored in a separate
single hash:
.PP
.Vb 1
\&    # Objects of this class have the following attributes...
\&
\&    my %root_of;   # The root directory of the file hierarchy
\&    my %files_of;  # Array storing object for each file in root directory
.Ve
.PP
This is 90 degrees to the usual hash-based approach. In hash-based
classes, all the attributes of one object are stored in a single hash;
in inside-out classes, one attribute from all objects is stored in a
single hash. Diagrammatically:
.PP
.Vb 2
\&    Hash\-based:
\&                     Attribute 1      Attribute 2
\&
\&     Object A    { attr1 => $valA1,  attr2 => $val2 }
\&
\&     Object B    { attr1 => $valB1,  attr2 => $val2 }
\&
\&     Object C    { attr1 => $valB1,  attr2 => $val2 }
\&
\&
\&
\&    Inside\-out:
\&                      Object A           Object B          Object C
\&
\&    Attribute 1  { 19817 => $valA1,  172616 => $valB1,  67142 => $valC1 }
\&
\&    Attribute 2  { 19817 => $valA2,  172616 => $valB2,  67142 => $valC3 }
\&
\&    Attribute 3  { 19817 => $valA3,  172616 => $valB3,  67142 => $valC3 }
.Ve
.PP
So the attributes belonging to each object are distributed across a set of
predeclared hashes, rather than being squashed together into one anonymous
hash.
.PP
This is a significant improvement. By telling Perl what attributes you
expect to use, you enable the compiler to check\*(--via use strict\*(--that
you do indeed use only those attributes.
.PP
That's because of the third difference in the two approaches. Each
attribute of a hash-based object is stored in an entry in the object's
hash: \f(CW\*(C`$self\->{name}\*(C'\fR. In other words, the name of a hash-based attribute
is symbolic: specified by the string value of a hash key. In contrast,
each attribute of an inside-out object is stored in an entry of the
attribute's hash: \f(CW$name_of{ident $self}\fR. So the name of an inside-out
attribute isn't symbolic; it's a hard-coded variable name.
.PP
With hash-based objects, if an attribute name is accidentally misspelled
in some method:
.PP
.Vb 2
\&    sub set_name {
\&        my ($self, $new_name) = @_;
\&
\&        $self\->{naem} = $new_name;             # Oops!
\&
\&        return;
\&    }
.Ve
.PP
then the \f(CW$self\fR hash will obligingly\*(--and silently!\-\-create a new entry
in the hash, with the key \f(CW\*(Aqnaem\*(Aq\fR, then assign the new name to it. But
since every other method in the class correctly refers to the attribute
as \f(CW\*(C`$self\-\*(C'\fR{name}>, assigning the new value to \f(CW\*(C`$self\-\*(C'\fR{naem}> effectively
makes that assigned value \*(L"vanish\*(R".
.PP
With inside-out objects, however, an object's \*(L"name\*(R" attribute is stored
as an entry in the class's lexical \f(CW%name_of\fR hash. If the attribute name
is misspelled then you're attempting to refer to an entirely different
hash: \f(CW%naem_of\fR. Like so:
.PP
.Vb 2
\&    sub set_name {
\&        my ($self, $new_name) = @_;
\&
\&        $naem_of{ident $self} = $new_name;     # Kaboom!
\&
\&        return;
\&    }
.Ve
.PP
But, since there's no such hash declared in the scope, use strict will
complain (with extreme prejudice):
.PP
.Vb 1
\&    Global symbol "%naem_of" requires explicit package name at Hierarchy.pm line 86
.Ve
.PP
Not only is that consistency check now automatic, it's also performed at
compile time.
.PP
The next difference is even more important and beneficial. Instead of
blessing an empty anonymous hash as the new object:
.PP
.Vb 1
\&    my $new_object = bless {}, $class;
.Ve
.PP
the inside-out constructor blesses an empty anonymous scalar:
.PP
.Vb 1
\&    my $new_object = bless \edo{my $anon_scalar}, $class;
.Ve
.PP
That odd-looking \f(CW\*(C`\edo{my $anon_scalar}\*(C'\fR construct is needed because
there's no built-in syntax in Perl for creating a reference to an
anonymous scalar; you have to roll-your-own.
.PP
The anonymous scalar is immediately passed to bless, which anoints it as
an object of the appropriate class. The resulting object reference is
then stored in \f(CW$new_object\fR.
.PP
Once the object exists, it's used to create a unique key
(\f(CW\*(C`ident $new_object\*(C'\fR) under which each attribute that belongs to the
object will be stored (e.g. \f(CW$root_of{ident $new_object}\fR or
\&\f(CW$name_of{ident $self}\fR). The \f(CW\*(C`ident()\*(C'\fR utility that produces this unique
key is provided by the Class::Std module and is identical in effect to
the \f(CW\*(C`refaddr()\*(C'\fR function in the standard Scalar::Util module.
.PP
To recap: every inside-out object is a blessed scalar, and
has\*(--intrinsic to it\*(--a unique identifying integer. That integer can be
obtained from the object reference itself, and then used to access a
unique entry for the object in each of the class's attribute hashes.
.PP
This means that every inside-out object is nothing more than an
unintialized scalar. When your constructor passes a new inside-out
object back to the client code, all that comes back is an empty scalar,
which makes it impossible for that client code to gain direct access to
the object's internal state.
.PP
Of the several popular methods of reliably enforcing encapsulation in
Perl, inside-out objects are also by far the cheapest. The run-time
performance of inside-out classes is effectively identical to that of
regular hash-based classes. In particular, in both schemes, every
attribute access requires only a single hash look-up. The only
appreciable difference in speed occurs when an inside-out object is
destroyed.
.PP
Hash-based classes usually don't even have destructors. When the
object's reference count decrements to zero, the hash is automatically
reclaimed, and any data structures stored inside the hash are likewise
cleaned up. This works so well that many \s-1OO\s0 Perl programmers find they
never need to write a \f(CW\*(C`DESTROY()\*(C'\fR method; Perl's built-in garbage
collection handles everything just fine. In fact, the only time a
destructor is needed is when objects have to manage resources outside
that are not actually located inside the object, resources that need to
be separately deallocated.
.PP
But the whole point of an inside-out object is that its attributes are
stored in allocated hashes that are not actually located inside the
object. That's precisely how it achieves secure encapsulation: by not
sending the attributes out into the client code.
.PP
Unfortunately, that means when an inside-out object is eventually
garbage collected, the only storage that is reclaimed is the single
blessed scalar implementing the object. The object's attributes are
entirely unaffected by the object's deallocation, because the attributes
are not inside the object, nor are they referred to by it in any way.
.PP
Instead, the attributes are referred to by the various attribute hashes
in which they're stored. And since those hashes will continue to exist
until the end of the program, the defunct object's orphaned attributes
will likewise continue to exist, safely nestled inside their respective
hashes, but now untended by any object. In other words, when an inside\-
out object dies, its associated attribute hashes leak memory.
.PP
The solution is simple. Every inside-out class has to provide a
destructor that \*(L"manually\*(R" cleans up the attributes of the object being
destructed:
.PP
.Vb 5
\&    package File::Hierarchy;
\&    {
\&        # Objects of this class have the following attributes...
\&        my %root_of;   # The root directory of the file hierarchy
\&        my %files_of;  # Array storing object for each file in root directory
\&        
\&        # Constructor takes path of file system root directory...
\&        sub new {
\&            # As before
\&        }
\&        
\&        # Retrieve files from root directory...
\&        sub get_files {
\&            # As before
\&        }
\&
\&        # Clean up attributes when object is destroyed...
\&        sub DESTROY {
\&            my ($self) = @_;
\&
\&            delete $root_of{ident $self};
\&            delete $files_of{ident $self};
\&        }
\&    }
.Ve
.PP
The obligation to provide a destructor like this in every inside-out
class can be mildly irritating, but it is still a very small price to
pay for the considerable benefits that the inside-out approach otherwise
provides for free. And the irritation can easily be eliminated by using
the appropriate class construction tools. See below.
.SS "Automating Inside-Out Classes"
.IX Subsection "Automating Inside-Out Classes"
Perhaps the most annoying part about building classes in Perl (no matter how
the objects are implemented) is that the basic structure of every class is 
more or less identical. For example, the implementation of the
\&\f(CW\*(C`File::Hierarchy::File\*(C'\fR class used in \f(CW\*(C`File::Hierarchy\*(C'\fR looks like this:
.PP
.Vb 4
\&    package File::Hierarchy::File;
\&    {    
\&        # Objects of this class have the following attributes...
\&        my %name_of;  # the name of the file
\&        
\&        # Constructor takes name of file...
\&        sub new {
\&            my ($class, $filename) = @_;
\&        
\&            # Bless a scalar to instantiate the new object...
\&            my $new_object = bless \edo{my $anon_scalar}, $class;
\&        
\&            # Initialize the object\*(Aqs "name" attribute...
\&            $name_of{ident $new_object} = $filename;
\&        
\&            return $new_object;
\&        }
\&        
\&        # Retrieve name of file...
\&        sub get_name {
\&            my ($self) = @_;
\&        
\&            return $name_of{ident $self};
\&        }
\&
\&        # Clean up attributes when object is destroyed...
\&        sub DESTROY {
\&            my ($self) = @_;
\&
\&            delete $name_of{ident $self};
\&        }
\&    }
.Ve
.PP
Apart from the actual names of the attributes, and their accessor methods,
that's exactly the same structure, and even the same code, as in the
\&\f(CW\*(C`File::Hierarchy\*(C'\fR class.
.PP
Indeed, the standard infrastructure of \fIevery\fR inside-out class looks
exactly the same. So it makes sense not to have to rewrite that standard
infrastructure code in every separate class.
.PP
That's precisely what this module does: it implements the necessary
infrastructure for inside-out objects. See below.
.SH "INTERFACE"
.IX Header "INTERFACE"
.SS "Exported subroutines"
.IX Subsection "Exported subroutines"
.ie n .IP """ident()""" 4
.el .IP "\f(CWident()\fR" 4
.IX Item "ident()"
Class::Std always exports a subroutine called \f(CW\*(C`ident()\*(C'\fR. This subroutine
returns a unique integer \s-1ID\s0 for any object passed to it.
.SS "Non-exported subroutines"
.IX Subsection "Non-exported subroutines"
.ie n .IP """Class::Std::initialize()""" 4
.el .IP "\f(CWClass::Std::initialize()\fR" 4
.IX Item "Class::Std::initialize()"
This subroutine sets up all the infrastructure to support your Class::Std\-
based class. It is usually called automatically in a \f(CW\*(C`CHECK\*(C'\fR block, or
(if the \f(CW\*(C`CHECK\*(C'\fR block fails to run \*(-- under \f(CW\*(C`mod_perl\*(C'\fR or \f(CW\*(C`require
Class::Std\*(C'\fR or \f(CW\*(C`eval "..."\*(C'\fR) during the first constructor call made to
a Class::Std\-based object.
.Sp
In rare circumstances, you may need to call this subroutine directly yourself.
Specifically, if you set up cumulative, restricted, private, or automethodical
class methods (see below), and call any of them before you create any objects,
then you need to call \f(CW\*(C`Class::Std::initialize()\*(C'\fR first.
.SS "Methods created automatically"
.IX Subsection "Methods created automatically"
The following subroutines are installed in any class that uses the
Class::Std module.
.ie n .IP """new()""" 4
.el .IP "\f(CWnew()\fR" 4
.IX Item "new()"
Every class that loads the Class::Std module automatically has a \f(CW\*(C`new()\*(C'\fR
constructor, which returns an inside-out object (i.e. a blessed scalar).
.Sp
.Vb 1
\&    $obj = MyClass\->new();
.Ve
.Sp
The constructor can be passed a single argument to initialize the
object. This argument must be a hash reference.
.Sp
.Vb 1
\&    $obj = MyClass\->new({ name=>\*(AqFoo\*(Aq, location=>\*(Aqbar\*(Aq });
.Ve
.Sp
See the subsequent descriptions of the \f(CW\*(C`BUILD()\*(C'\fR and \f(CW\*(C`START()\*(C'\fR methods
and \f(CW\*(C`:ATTR()\*(C'\fR trait, for an explanation of how the contents of this
optional hash can be used to initialize the object.
.Sp
It is almost always an error to implement your own \f(CW\*(C`new()\*(C'\fR in any class
that uses Class::Std. You almost certainly want to write a \f(CW\*(C`BUILD()\*(C'\fR or
\&\f(CW\*(C`START()\*(C'\fR method instead. See below.
.ie n .IP """DESTROY()""" 4
.el .IP "\f(CWDESTROY()\fR" 4
.IX Item "DESTROY()"
Every class that loads the Class::Std module automatically has a \f(CW\*(C`DESTROY()\*(C'\fR
destructor, which automatically cleans up any attributes declared with the
\&\f(CW\*(C`:ATTR()\*(C'\fR trait (see below).
.Sp
It is almost always an error to write your own \f(CW\*(C`DESTROY()\*(C'\fR in any class that
uses Class::Std. You almost certainly want to write your own \f(CW\*(C`DEMOLISH()\*(C'\fR
instead. See below.
.ie n .IP """AUTOLOAD()""" 4
.el .IP "\f(CWAUTOLOAD()\fR" 4
.IX Item "AUTOLOAD()"
Every class that loads the Class::Std module automatically has an
\&\f(CW\*(C`AUTOLOAD()\*(C'\fR method, which implements the \f(CW\*(C`AUTOMETHOD()\*(C'\fR mechanism
described below.
.Sp
It is almost always an error to write your own \f(CW\*(C`AUTOLOAD()\*(C'\fR in any class that
uses Class::Std. You almost certainly want to write your own \f(CW\*(C`AUTOMETHOD()\*(C'\fR
instead.
.ie n .IP """_DUMP()""" 4
.el .IP "\f(CW_DUMP()\fR" 4
.IX Item "_DUMP()"
This method returns a string that represents the internal state (i.e. the
attribute values) of the object on which it's called. Only those attributes
which are marked with an \f(CW\*(C`:ATTR\*(C'\fR (see below) are reported. Attribute names
are reported only if they can be ascertained from an \f(CW\*(C`:init_arg\*(C'\fR, \f(CW\*(C`:get\*(C'\fR, or
\&\f(CW\*(C`:set\*(C'\fR option within the \f(CW\*(C`:ATTR()\*(C'\fR.
.Sp
Note that \f(CW\*(C`_DUMP()\*(C'\fR is not designed to support full
serialization/deserialization of objects. See the separate
Class::Std::Storable module (on \s-1CPAN\s0) for that.
.SS "Methods that can be supplied by the developer"
.IX Subsection "Methods that can be supplied by the developer"
The following subroutines can be specified as standard methods of a
Class::Std class.
.ie n .IP """BUILD()""" 4
.el .IP "\f(CWBUILD()\fR" 4
.IX Item "BUILD()"
When the \f(CW\*(C`new()\*(C'\fR constructor of a Class::Std class is called, it
automatically calls every method named \f(CW\*(C`BUILD()\*(C'\fR in \fIall\fR the classes
in the new object's hierarchy. That is, when the constructor is called,
it walks the class's inheritance tree (from base classes downwards) and
calls every \f(CW\*(C`BUILD()\*(C'\fR method it finds along the way.
.Sp
This means that, to initialize any class, you merely need to provide a
\&\f(CW\*(C`BUILD()\*(C'\fR method for that class. You don't have to worry about ensuring
that any ancestral \f(CW\*(C`BUILD()\*(C'\fR methods also get called; the constructor
will take care of that.
.Sp
Each \f(CW\*(C`BUILD()\*(C'\fR method is called with three arguments: the invocant object,
the identifier number of that object, and a reference to (a customized version
of) the hash of arguments that was originally passed to the constructor:
.Sp
.Vb 4
\&    sub BUILD {
\&        my ($self, $ident, $args_ref) = @_;
\&        ...
\&    }
.Ve
.Sp
The argument hash is a \*(L"customized version\*(R" because the module
automatically does some fancy footwork to ensure that the arguments are
the ones appropriate to the class itself. That's because there's a
potential for collisions when Class::Std classes are used in a
hierarchy.
.Sp
One of the great advantages of using inside-out classes instead of hash-based
classes is that an inside-out base class and an inside-out derived
class can then each have an attribute of exactly the same name, which
are stored in separate lexical hashes in separate scopes. In a hash-based
object that's impossible, because the single hash can't have two
attributes with the same key.
.Sp
But that very advantage also presents something of a problem when
constructor arguments are themselves passed by hash. If two or more
classes in the name hierarchy do happen to have attributes of the same
name, the constructor will need two or more initializers with the name
key. Which a single hash can't provide.
.Sp
The solution is to allow initializer values to be partitioned into
distinct sets, each uniquely named, and which are then passed to the
appropriate base class. The easiest way to accomplish that is to pass
in a hash of hashes, where each top level key is the name of one of
the base classes, and the corresponding value is a hash of
initializers specifically for that base class.
.Sp
For example:
.Sp
.Vb 5
\&    package Client;
\&    use Class::Std::Utils;
\&    {
\&        my %client_num_of :ATTR;  # Every client has a basic ID number
\&        my %name_of       :ATTR;
\&
\&        sub BUILD {
\&            my ($self, $ident, $arg_ref) = @_;
\&
\&            $client_num_of{$ident} = $arg_ref\->{\*(AqClient\*(Aq}{client_num};
\&            $name_of{$ident}       = $arg_ref\->{\*(AqClient\*(Aq}{client_name};
\&        }
\&    }
\&
\&    package Client::Corporate;
\&    use base qw( Client );
\&    use Class::Std::Utils;
\&    {
\&        my %client_num_of;     # Corporate clients have an additional ID number
\&        my %corporation_of;
\&        my %position_of; 
\&
\&        sub BUILD {
\&            my ($self, $ident, $arg_ref) = @_;
\&
\&            $client_num_of{$ident} 
\&                = $arg_ref\->{\*(AqClient::Corporate\*(Aq}{client_num};
\&            $corporation_of{$ident}
\&                = $arg_ref\->{\*(AqClient::Corporate\*(Aq}{corp_name};
\&            $position_of{$ident}
\&                = $arg_ref\->{\*(AqClient::Corporate\*(Aq}{position};
\&        }
\&    }
\&
\&    # and later...
\&
\&    my $new_client 
\&        = Client::Corporate\->new( {
\&            \*(AqClient\*(Aq => { 
\&                client_num  => \*(Aq124C1\*(Aq, 
\&                client_name => \*(AqHumperdinck\*(Aq,
\&            },
\&            \*(AqClient::Corporate\*(Aq => { 
\&                client_num  => \*(AqF_1692\*(Aq, 
\&                corp_name   => \*(AqFlorin\*(Aq, 
\&                position    => \*(AqCEO\*(Aq,
\&            },
\&        });
.Ve
.Sp
Now each class's \f(CW\*(C`BUILD()\*(C'\fR method picks out only the initializer sub-hash
whose key is that class's own name. Since every class name is
different, the top-level keys of this multi-level initializer hash are
guaranteed to be unique. And since no single class can have two
identically named attributes, the keys of each second-level hash will be
unique as well. If two classes in the hierarchy both need an initializer
of the same name (e.g. 'client_num'), those two hash entries will now be
in separate sub-hashes, so they will never clash.
.Sp
Class::Std provides an even more sophisticated variation on this
functionality, which is generally much more convenient for the users of
classes. Classes that use Class::Std infrastructure allow both general
and class-specific initializers in the initialization hash. Clients only
need to specify classes for those initializers whose names actually are
ambiguous. Any other arguments can just be passed directly in the
top-level hash:
.Sp
.Vb 5
\&    my $new_client 
\&        = Client::Corporate\->new( {
\&            client_name => \*(AqHumperdinck\*(Aq,
\&            corp_name   => \*(AqFlorin\*(Aq, 
\&            position    => \*(AqCEO\*(Aq,
\&
\&            \*(AqClient\*(Aq            => { client_num  => \*(Aq124C1\*(Aq  }, 
\&            \*(AqClient::Corporate\*(Aq => { client_num  => \*(AqF_1692\*(Aq },
\&        });
.Ve
.Sp
Class::Std also makes it easy for each class's \f(CW\*(C`BUILD()\*(C'\fR to access
these class-specific initializer values. Before each \f(CW\*(C`BUILD()\*(C'\fR is
invoked, the nested hash whose key is the same as the class name is
flattened back into the initializer hash itself. That is, \f(CW\*(C`Client::BUILD()\*(C'\fR
is passed the hash:
.Sp
.Vb 5
\&    {
\&        client_name => \*(AqHumperdinck\*(Aq,
\&        corp_name   => \*(AqFlorin\*(Aq, 
\&        position    => \*(AqCEO\*(Aq,
\&        client_num  => \*(Aq124C1\*(Aq,   # Flattened from \*(AqClient\*(Aq nested subhash
\&
\&        \*(AqClient\*(Aq            => { client_num  => \*(Aq124C1\*(Aq  }, 
\&        \*(AqClient::Corporate\*(Aq => { client_num  => \*(AqF_1692\*(Aq },
\&    }
.Ve
.Sp
whereas \f(CW\*(C`Client::Corporate::BUILD()\*(C'\fR is passed the hash:
.Sp
.Vb 5
\&    {
\&        client_name => \*(AqHumperdinck\*(Aq,
\&        corp_name   => \*(AqFlorin\*(Aq, 
\&        position    => \*(AqCEO\*(Aq,
\&        client_num  => \*(AqF_1692\*(Aq,   # Flattened from \*(AqClient::Corporate\*(Aq subhash
\&
\&        \*(AqClient\*(Aq            => { client_num  => \*(Aq124C1\*(Aq  }, 
\&        \*(AqClient::Corporate\*(Aq => { client_num  => \*(AqF_1692\*(Aq },
\&    }
.Ve
.Sp
This means that the \f(CW\*(C`BUILD()\*(C'\fR method for each class can just assume that the
correct class-specific initializer values will available at the top level of
the hash. For example:
.Sp
.Vb 2
\&        sub Client::BUILD {
\&            my ($self, $ident, $arg_ref) = @_;
\&
\&            $client_num_of{$ident} = $arg_ref\->{client_num};    # \*(Aq124C1\*(Aq
\&            $name_of{$ident}       = $arg_ref\->{client_name};
\&        }
\&
\&        sub Client::Corporate::BUILD {
\&            my ($self, $ident, $arg_ref) = @_;
\&
\&            $client_num_of{$ident}  = $arg_ref\->{client_num};   # \*(AqF_1692\*(Aq
\&            $corporation_of{$ident} = $arg_ref\->{corp_name};
\&            $position_of{$ident}    = $arg_ref\->{position};
\&        }
.Ve
.Sp
Both classes use the \f(CW\*(C`$arg_ref\->{client_num}\*(C'\fR initializer value, but
Class::Std automatically arranges for that value to be the right one for each
class.
.Sp
Also see the \f(CW\*(C`:ATTR()\*(C'\fR marker (described below) for a simpler way of
initializing attributes.
.ie n .IP """START()""" 4
.el .IP "\f(CWSTART()\fR" 4
.IX Item "START()"
Once all the \f(CW\*(C`BUILD()\*(C'\fR methods of a class have been called and any
initialization values or defaults have been subsequently applied to
uninitialized attributes, Class::Std arranges for any \f(CW\*(C`START()\*(C'\fR methods
in the class's hierarchy to be called befre the constructor finishes.
That is, after the build and default initialization processes are
complete, the constructor walks down the class's inheritance tree a
second time and calls every \f(CW\*(C`START()\*(C'\fR method it finds along the way.
.Sp
As with \f(CW\*(C`BUILD()\*(C'\fR, each \f(CW\*(C`START()\*(C'\fR method is called with three arguments:
the invocant object, the identifier number of that object, and a
reference to (a customized version of) the hash of arguments that was
originally passed to the constructor.
.Sp
The main difference between a \f(CW\*(C`BUILD()\*(C'\fR method and a \f(CW\*(C`START()\*(C'\fR method
is that a \f(CW\*(C`BUILD()\*(C'\fR method runs before any attribute of the class is
auto-initialized or default-initialized, whereas a \f(CW\*(C`START()\*(C'\fR method
runs after all the attributes of the class (including attributes in derived
classes) have been initialized in some way. So if you want to pre-empt
the initialization process, write a \f(CW\*(C`BUILD()\*(C'\fR. But if you want to do
something with the newly created and fully initialized object, write a
\&\f(CW\*(C`START()\*(C'\fR instead. Of course, any class can define \fIboth\fR a \f(CW\*(C`BUILD()\*(C'\fR
and a \f(CW\*(C`START()\*(C'\fR method, if that happens to be appropriate.
.ie n .IP """DEMOLISH()""" 4
.el .IP "\f(CWDEMOLISH()\fR" 4
.IX Item "DEMOLISH()"
The \f(CW\*(C`DESTROY()\*(C'\fR method that is automatically provided by Class::Std ensures
that all the marked attributes (see the \f(CW\*(C`:ATTR()\*(C'\fR marker below) of an object,
from all the classes in its inheritance hierarchy, are automatically cleaned
up.
.Sp
But, if a class requires other destructor behaviours (e.g. closing
filehandles, decrementing allocation counts, etc.) then you may need to
specify those explicitly.
.Sp
Whenever an object of a Class::Std class is destroyed, the \f(CW\*(C`DESTROY()\*(C'\fR
method supplied by Class::Std automatically calls every method named
\&\f(CW\*(C`DEMOLISH()\*(C'\fR in \fIall\fR the classes in the new object's hierarchy. That
is, when the destructor is called, it walks the class's inheritance
tree (from derived classes upwards) and calls every \f(CW\*(C`DEMOLISH()\*(C'\fR method it
finds along the way.
.Sp
This means that, to clean up any class, you merely need to provide a
\&\f(CW\*(C`DEMOLISH()\*(C'\fR method for that class. You don't have to worry about ensuring
that any ancestral \f(CW\*(C`DEMOLISH()\*(C'\fR methods also get called; the destructor
will take care of that.
.Sp
Each \f(CW\*(C`DEMOLISH()\*(C'\fR method is called with two arguments: the invocant object,
and the identifier number of that object. For example:
.Sp
.Vb 2
\&    sub DEMOLISH {
\&        my ($self, $ident) = @_;
\&
\&        $filehandle_of{$ident}\->flush();
\&        $filehandle_of{$ident}\->close();
\&    }
.Ve
.Sp
Note that the attributes of the object are cleaned up \fIafter\fR the
\&\f(CW\*(C`DEMOLISH()\*(C'\fR method is complete, so they may still be used within
that method.
.ie n .IP """AUTOMETHOD()""" 4
.el .IP "\f(CWAUTOMETHOD()\fR" 4
.IX Item "AUTOMETHOD()"
There is a significant problem with Perl's built-in \f(CW\*(C`AUTOLOAD\*(C'\fR mechanism:
there's no way for a particular \f(CW\*(C`AUTOLOAD()\*(C'\fR to say \*(L"no\*(R".
.Sp
If two or more classes in a class hierarchy have separate \f(CW\*(C`AUTOLOAD()\*(C'\fR
methods, then the one belonging to the left-most-depth-first class in
the inheritance tree will always be invoked in preference to any others.
If it can't handle a particular call, the call will probably fail
catastrophically. This means that derived classes can't always be used
in place of base classes (a feature known as \*(L"Liskov substitutability\*(R")
because their inherited autoloading behaviour may be pre-empted by some
other unrelated base class on their left in the hierarchy.
.Sp
Class::Std provides a mechanism that solves this problem: the
\&\f(CW\*(C`AUTOMETHOD\*(C'\fR method. An \s-1\fIAUTOMETHOD\s0()\fR is expected to return either a
handler subroutine that implements the requested method functionality,
or else an \f(CW\*(C`undef\*(C'\fR to indicate that it doesn't know how to handle the
request. Class::Std then coordinates every \f(CW\*(C`AUTOMETHOD()\*(C'\fR in an object's
hierarchy, trying each one in turn until one of them produces a
suitable handler.
.Sp
The advantage of this approach is that the first \f(CW\*(C`AUTOMETHOD()\*(C'\fR that's
invoked doesn't have to disenfranchise every other \f(CW\*(C`AUTOMETHOD()\*(C'\fR in the
hierarchy. If the first one can't handle a particular method call, it
simply declines it and Class::Std tries the next candidate instead.
.Sp
Using \f(CW\*(C`AUTOMETHOD()\*(C'\fR instead of \f(CW\*(C`AUTOLOAD()\*(C'\fR makes a class
cleaner, more robust, and less disruptive in class hierarchies.
For example:
.Sp
.Vb 4
\&    package Phonebook;
\&    use Class::Std;
\&    {
\&        my %entries_of : ATTR;
\&
\&        # Any method call is someone\*(Aqs name:
\&        # so store their phone number or get it...
\&        sub AUTOMETHOD {
\&            my ($self, $ident, $number) = @_;
\&
\&            my $subname = $_;   # Requested subroutine name is passed via $_
\&
\&            # Return failure if not a get_<name> or set_<name>
\&            # (Next AUTOMETHOD() in hierarchy will then be tried instead)...
\&            my ($mode, $name) = $subname =~ m/\eA ([gs]et)_(.*) \ez/xms
\&                or return;
\&
\&            # If get_<name>, return a handler that just returns the old number...
\&            return sub { return $entries_of{$ident}\->{$name}; }
\&                if $mode eq \*(Aqget\*(Aq;
\&
\&            # Otherwise, set_<name>, so return a handler that
\&            # updates the entry and then returns the old number...
\&            return sub {
\&                $entries_of{$ident}\->{$name} = $number;
\&                return;
\&            };
\&        }
\&    }
\&
\&    # and later...
\&
\&    my $lbb = Phonebook\->new();
\&
\&    $lbb\->set_Jenny(867_5309);
\&    $lbb\->set_Glenn(736_5000);
\&
\&    print $lbb\->get_Jenny(), "\en";
\&    print $lbb\->get_Glenn(), "\en";
.Ve
.Sp
Note that, unlike \f(CW\*(C`AUTOLOAD()\*(C'\fR, an \f(CW\*(C`AUTOMETHOD()\*(C'\fR is called with both the
invocant and the invocant's unique \f(CW\*(C`ident\*(C'\fR number, followed by the actual
arguments that were passed to the method.
.Sp
Note too that the name of the method being called is passed as \f(CW$_\fR
instead of \f(CW$AUTOLOAD\fR, and does \fInot\fR have the class name prepended
to it, so you don't have to strip that name off the front like almost
everyone almost always does in their \f(CW\*(C`AUTOLOAD()\*(C'\fR. If your \f(CW\*(C`AUTOMETHOD()\*(C'\fR
also needs to access the \f(CW$_\fR from the caller's scope, that's still
available as \f(CW$CALLER::_\fR.
.SS "Variable traits that can be ascribed"
.IX Subsection "Variable traits that can be ascribed"
The following markers can be added to the definition of any hash
used as an attribute storage within a Class::Std class
.ie n .IP """:ATTR()""" 4
.el .IP "\f(CW:ATTR()\fR" 4
.IX Item ":ATTR()"
This marker can be used to indicate that a lexical hash is being used
to store one particular attribute of all the objects of the class. That is:
.Sp
.Vb 4
\&    package File::Hierarchy;
\&    {
\&        my %root_of  :ATTR;  
\&        my %files_of :ATTR;
\&        
\&        # etc.
\&    }
\&
\&    package File::Hierarchy::File;
\&    {    
\&        my %name_of;  :ATTR;
\&
\&        # etc.
\&    }
.Ve
.Sp
Adding the \f(CW\*(C`:ATTR\*(C'\fR marker to an attribute hash ensures that the corresponding 
attribute belonging to each object of the class is automatically cleaned up 
when the object is destroyed.
.Sp
The \f(CW\*(C`:ATTR\*(C'\fR marker can also be given a number of options which automate
other attribute-related behaviours. Each of these options consists of a
key/value pair, which may be specified in either Perl 5 \*(L"fat comma\*(R" syntax
( \f(CW\*(C`key\ =>\ \*(Aqvalue\*(Aq\*(C'\fR ) or in one of the Perl 6 option syntaxes
( \f(CW\*(C`:key<value>\*(C'\fR or \f(CW\*(C`:key(\*(Aqvalue\*(Aq)\*(C'\fR or 
\&\f(CW\*(C`:keyXvalueX\*(C'\fR).
.Sp
Note that, due to a limitation in Perl itself, the complete \f(CW\*(C`:ATTR\*(C'\fR marker,
including its options must appear on a single line.
interpolate variables into the option values
.RS 4
.ie n .IP """:ATTR( :init_arg<initializer_key> )""" 4
.el .IP "\f(CW:ATTR( :init_arg<initializer_key> )\fR" 4
.IX Item ":ATTR( :init_arg<initializer_key> )"
This option tells Class::Std which key in the constructor's initializer hash
holds the value with which the marked attribute should be initialized. That
is, instead of writing:
.Sp
.Vb 1
\&    my %rank_of :ATTR;
\&
\&    sub BUILD {
\&        my ($self, $ident, $arg_ref) = @_;
\&
\&        $rank_of{$ident} = $arg_ref\->{rank};
\&    }
.Ve
.Sp
you can achieve the same initialization, by having Class::Std \fIautomatically\fR
pull that entry out of the hash and store it in the right attribute:
.Sp
.Vb 1
\&    my %rank_of :ATTR( :init_arg<rank> );
\&
\&    # No BUILD() method required
.Ve
.ie n .IP """:ATTR( :default<compile_time_default_value> )""" 4
.el .IP "\f(CW:ATTR( :default<compile_time_default_value> )\fR" 4
.IX Item ":ATTR( :default<compile_time_default_value> )"
If a marked attribute is not initialized (either directly within a
\&\f(CW\*(C`BUILD()\*(C'\fR, or automatically via an \f(CW\*(C`:init_arg\*(C'\fR option), the constructor
supplied by Class::Std checks to see if a default value was specified
for that attribute. If so, that value is assigned to the attribute.
.Sp
So you could replace:
.Sp
.Vb 1
\&    my %seen_of :ATTR;
\&
\&    sub BUILD {
\&        my ($self, $ident, $arg_ref) = @_;
\&
\&        $seen_of{$ident} = 0;  # Not seen yet
\&    }
.Ve
.Sp
with:
.Sp
.Vb 1
\&    my %seen_of :ATTR( :default(0) );
\&
\&    # No BUILD() required
.Ve
.Sp
Note that only literal strings and numbers can be used as default values. A
common mistake is to write:
.Sp
.Vb 1
\&    my %seen_of :ATTR( :default($some_variable) );
.Ve
.Sp
But variables like this aren't interpolated into \f(CW\*(C`:ATTR\*(C'\fR markers (this is a
limitation of Perl, not Class::Std).
.Sp
If your attribute needs something more complex, you will have to default
initialize it in a \f(CW\*(C`START()\*(C'\fR method:
.Sp
.Vb 1
\&    my %seen_of :ATTR;
\&
\&    sub START {
\&        my ($self, $id, $args_ref) = @_;
\&
\&        if (!defined $seen_of{$id}) {
\&            $seen_of{$id} = $some_variable;
\&        }
\&    }
.Ve
.ie n .IP """:ATTR( :get<name> )""" 4
.el .IP "\f(CW:ATTR( :get<name> )\fR" 4
.IX Item ":ATTR( :get<name> )"
If the \f(CW\*(C`:get\*(C'\fR option is specified, a read accessor is created for the
corresponding attribute. The name of the accessor is \f(CW\*(C`get_\*(C'\fR followed by
whatever name is specified as the value of the \f(CW\*(C`:get\*(C'\fR option. For example,
instead of:
.Sp
.Vb 1
\&    my %current_count_of :ATTR;
\&
\&    sub get_count {
\&        my ($self) = @_;
\&
\&        return $current_count_of{ident($self)};
\&    }
.Ve
.Sp
you can just write:
.Sp
.Vb 1
\&    my %count_of :ATTR( :get<count> );
.Ve
.Sp
Note that there is no way to prevent Class::Std adding the initial \f(CW\*(C`get_\*(C'\fR to
each accessor name it creates. That's what \*(L"standard\*(R" means. See Chapter 15
of \fIPerl Best Practices\fR (O'Reilly, 2005) for a full discussion on why
accessors should be named this way.
.ie n .IP """:ATTR( :set<name> )""" 4
.el .IP "\f(CW:ATTR( :set<name> )\fR" 4
.IX Item ":ATTR( :set<name> )"
If the \f(CW\*(C`:set\*(C'\fR option is specified, a write accessor is created for the
corresponding attribute. The name of the accessor is \f(CW\*(C`set_\*(C'\fR followed by
whatever name is specified as the value of the \f(CW\*(C`:set\*(C'\fR option. For example,
instead of:
.Sp
.Vb 1
\&    my %current_count_of :ATTR;
\&
\&    sub set_count {
\&        my ($self, $new_value) = @_;
\&
\&        croak "Missing new value in call to \*(Aqset_count\*(Aq method"
\&            unless @_ == 2;
\&
\&        $current_count_of{ident($self)} = $new_value;
\&    }
.Ve
.Sp
you can just write:
.Sp
.Vb 1
\&    my %count_of :ATTR( :set<count> );
.Ve
.Sp
Note that there is no way to prevent Class::Std adding the initial
\&\f(CW\*(C`set_\*(C'\fR to each accessor name it creates. Nor is there any way to create
a combined \*(L"getter/setter\*(R" accessor. See Chapter 15 of \fIPerl Best
Practices\fR (O'Reilly, 2005) for a full discussion on why accessors
should be named and implemented this way.
.ie n .IP """:ATTR( :name<name> )""" 4
.el .IP "\f(CW:ATTR( :name<name> )\fR" 4
.IX Item ":ATTR( :name<name> )"
Specifying the \f(CW\*(C`:name\*(C'\fR option is merely a convenient 
shorthand for specifying all three of \f(CW\*(C`:get\*(C'\fR, \f(CW\*(C`:set\*(C'\fR, and \f(CW\*(C`:init_arg\*(C'\fR.
.RE
.RS 4
.Sp
You can, of course, specify two or more arguments in a single \f(CW\*(C`:ATTR()\*(C'\fR
specification:
.Sp
.Vb 1
\&    my %rank_of : ATTR( :init_arg<starting_rank>  :get<rank>  :set<rank> );
.Ve
.RE
.ie n .IP """:ATTRS()""" 4
.el .IP "\f(CW:ATTRS()\fR" 4
.IX Item ":ATTRS()"
This is just another name for the \f(CW\*(C`:ATTR\*(C'\fR marker (see above). The plural
form is convenient when you want to specify a series of attribute hashes in
the same statement:
.Sp
.Vb 9
\&    my (
\&        %name_of,
\&        %rank_of,
\&        %snum_of,
\&        %age_of,
\&        %unit_of,
\&        %assignment_of,
\&        %medals_of,
\&    ) : ATTRS;
.Ve
.SS "Method traits that can be ascribed"
.IX Subsection "Method traits that can be ascribed"
The following markers can be added to the definition of any subroutine
used as a method within a Class::Std class
.ie n .IP """:RESTRICTED()""" 4
.el .IP "\f(CW:RESTRICTED()\fR" 4
.IX Item ":RESTRICTED()"
.PD 0
.ie n .IP """:PRIVATE()""" 4
.el .IP "\f(CW:PRIVATE()\fR" 4
.IX Item ":PRIVATE()"
.PD
Occasionally, it is useful to be able to create subroutines that can only be
accessed within a class's own hierarchy (that is, by derived classes). And
sometimes it's even more useful to be able to create methods that can only be
called within a class itself.
.Sp
Typically these types of methods are \fIutility\fR methods: subroutines
that provide some internal service for a class, or a class hierarchy.
Class::Std supports the creation of these kinds of methods by providing two
special markers: \f(CW\*(C`:RESTRICTED()\*(C'\fR and \f(CW\*(C`:PRIVATE()\*(C'\fR.
.Sp
Methods marked \f(CW\*(C`:RESTRICTED()\*(C'\fR are modified at the end of the
compilation phase so that they throw an exception when called from
outside a class's hierarchy. Methods marked \f(CW\*(C`:PRIVATE()\*(C'\fR are modified
so that they throw an exception when called from outside the class in
which they're declared.
.Sp
For example:
.Sp
.Vb 5
\&    package DogTag;
\&    use Class::Std;
\&    {
\&        my %ID_of   : ATTR;
\&        my %rank_of : ATTR;
\&
\&        my $ID_num = 0;
\&
\&        sub _allocate_next_ID : RESTRICTED {
\&            my ($self) = @_;
\&            $ID_of{ident $self} = $ID_num++;
\&            return;
\&        }
\&
\&        sub _check_rank : PRIVATE {
\&            my ($rank) = @_;
\&            return $rank if $VALID_RANK{$rank};
\&            croak "Unknown rank ($rank) specified";
\&        }
\&
\&        sub BUILD {
\&            my ($self, $ident, $arg_ref) = @_;
\&
\&            $self\->_allocate_next_ID();
\&            $rank_of{$ident} = _check_rank($arg_ref\->{rank});
\&        }
\&    }
.Ve
.Sp
Of course, this code would run exactly the same without the \f(CW\*(C`:RESTRICTED()\*(C'\fR
and \f(CW\*(C`:PRIVATE()\*(C'\fR markers, but they ensure that any attempt to call the two
subroutines inappropriately:
.Sp
.Vb 1
\&    package main;
\&
\&    my $dogtag = DogTag\->new({ rank => \*(AqPFC\*(Aq });
\&
\&    $dogtag\->_allocate_next_ID();
.Ve
.Sp
is suitably punished:
.Sp
.Vb 1
\&    Can\*(Aqt call restricted method DogTag::_allocate_next_ID() from class main
.Ve
.ie n .IP """:CUMULATIVE()""" 4
.el .IP "\f(CW:CUMULATIVE()\fR" 4
.IX Item ":CUMULATIVE()"
One of the most important advantages of using the \f(CW\*(C`BUILD()\*(C'\fR and \f(CW\*(C`DEMOLISH()\*(C'\fR
mechanisms supplied by Class::Std is that those methods don't require
nested calls to their ancestral methods, via the \f(CW\*(C`SUPER\*(C'\fR pseudo-class. The
constructor and destructor provided by Class::Std take care of the
necessary redispatching automatically. Each \f(CW\*(C`BUILD()\*(C'\fR method can focus
solely on its own responsibilities; it doesn't have to also help
orchestrate the cumulative constructor effects across the class
hierarchy by remembering to call \f(CW\*(C`$self\->SUPER::BUILD()\*(C'\fR.
.Sp
Moreover, calls via \f(CW\*(C`SUPER\*(C'\fR can only ever call the method of exactly one
ancestral class, which is not sufficient under multiple inheritance.
.Sp
Class::Std provides a different way of creating methods whose effects
accumulate through a class hierarchy, in the same way as those of
\&\f(CW\*(C`BUILD()\*(C'\fR and \f(CW\*(C`DEMOLISH()\*(C'\fR do. Specifically, the module allows you to define
your own \*(L"cumulative methods\*(R".
.Sp
An ordinary non-cumulative method hides any method of the same name
inherited from any base class, so when a non-cumulative method is
called, only the most-derived version of it is ever invoked. In
contrast, a cumulative method doesn't hide ancestral methods of the same
name; it assimilates them. When a cumulative method is called, the
most-derived version of it is invoked, then any parental versions, then any
grandparental versions, etc. etc, until every cumulative method of the
same name throughout the entire hierarchy has been called.
.Sp
For example, you could define a cumulative \f(CW\*(C`describe()\*(C'\fR method to the various
classes in a simple class hierarchy like so:
.Sp
.Vb 5
\&    package Wax::Floor;
\&    use Class::Std;
\&    {
\&        my %name_of    :ATTR( init_arg => \*(Aqname\*(Aq   );
\&        my %patent_of  :ATTR( init_arg => \*(Aqpatent\*(Aq );
\&
\&        sub describe :CUMULATIVE {
\&            my ($self) = @_;
\&
\&            print "The floor wax $name_of{ident $self} ",
\&                  "(patent: $patent_of{ident $self})\en";
\&
\&            return;
\&        }
\&    }
\&
\&    package Topping::Dessert;
\&    use Class::Std;
\&    {
\&        my %name_of     :ATTR( init_arg => \*(Aqname\*(Aq    );
\&        my %flavour_of  :ATTR( init_arg => \*(Aqflavour\*(Aq );
\&
\&        sub describe :CUMULATIVE {
\&            my ($self) = @_;
\&
\&            print "The dessert topping $name_of{ident $self} ",
\&                  "with that great $flavour_of{ident $self} taste!\en";
\&
\&            return;
\&        }
\&    }
\&
\&    package Shimmer;
\&    use base qw( Wax::Floor  Topping::Dessert );
\&    use Class::Std;
\&    {
\&        my %name_of    :ATTR( init_arg => \*(Aqname\*(Aq   );
\&        my %patent_of  :ATTR( init_arg => \*(Aqpatent\*(Aq );
\&
\&        sub describe :CUMULATIVE {
\&            my ($self) = @_;
\&
\&            print "New $name_of{ident $self} ",
\&                  "(patent: $patent_of{ident $self})\en",
\&                  "Combining...\en";
\&
\&            return;
\&        }
\&    }
.Ve
.Sp
Because the various \f(CW\*(C`describe()\*(C'\fR methods are marked as being cumulative, a
subsequent call to:
.Sp
.Vb 6
\&    my $product 
\&        = Shimmer\->new({
\&              name    => \*(AqShimmer\*(Aq,
\&              patent  => 1562516251,
\&              flavour => \*(AqVanilla\*(Aq,
\&          });
\&
\&    $product\->describe();
.Ve
.Sp
will work its way up through the classes of Shimmer's inheritance tree
(in the same order as a destructor call would), calling each \f(CW\*(C`describe()\*(C'\fR
method it finds along the way. So the single call to \f(CW\*(C`describe()\*(C'\fR would
invoke the corresponding method in each class, producing:
.Sp
.Vb 4
\&    New Shimmer (patent: 1562516251)
\&    Combining...
\&    The floor wax Shimmer (patent: 1562516251)
\&    The dessert topping Shimmer with that great Vanilla taste!
.Ve
.Sp
Note that the accumulation of \f(CW\*(C`describe()\*(C'\fR methods is hierarchical, and
dynamic in nature. That is, each class only sees those cumulative
methods that are defined in its own package or in one of its ancestors.
So calling the same \f(CW\*(C`describe()\*(C'\fR on a base class object:
.Sp
.Vb 2
\&    my $wax 
\&        = Wax::Floor\->new({ name=>\*(AqShimmer \*(Aq, patent=>1562516251 });
\&
\&    $wax\->describe();
.Ve
.Sp
only invokes the corresponding cumulative methods from that point on up
the hierarchy, and hence only prints:
.Sp
.Vb 1
\&    The floor wax Shimmer (patent: 1562516251)
.Ve
.Sp
Cumulative methods also accumulate their return values. In a list
context, they return a (flattened) list that accumulates the lists
returned by each individual method invoked.
.Sp
In a scalar context, a set of cumulative methods returns an object that,
in a string context, concatenates individual scalar returns to produce a
single string. When used as an array reference that same scalar-context-return
object acts like an array of the list context values. When used as a hash
reference, the object acts like a hash whose keys are the classnames from the
object's hierarchy, and whose corresponding values are the return values of
the cumulative method from that class.
.Sp
For example, if the classes each have a cumulative method that returns
their list of sales features:
.Sp
.Vb 7
\&    package Wax::Floor;
\&    use Class::Std;
\&    {
\&        sub feature_list :CUMULATIVE {
\&            return (\*(AqLong\-lasting\*(Aq, \*(AqNon\-toxic\*(Aq, \*(AqPolymer\-based\*(Aq);
\&        }
\&    }
\&
\&    package Topping::Dessert;
\&    use Class::Std;
\&    {
\&        sub feature_list :CUMULATIVE {
\&            return (\*(AqLow\-carb\*(Aq, \*(AqNon\-dairy\*(Aq, \*(AqSugar\-free\*(Aq);
\&        }
\&    }
\&
\&    package Shimmer;
\&    use Class::Std;
\&    use base qw( Wax::Floor  Topping::Dessert );
\&    {
\&        sub feature_list :CUMULATIVE {
\&            return (\*(AqMulti\-purpose\*(Aq, \*(AqTime\-saving\*(Aq, \*(AqEasy\-to\-use\*(Aq);
\&        }
\&    }
.Ve
.Sp
then calling \fIfeature_list()\fR in a list context:
.Sp
.Vb 2
\&    my @features = Shimmer\->feature_list();
\&    print "Shimmer is the @features alternative!\en";
.Ve
.Sp
would produce a concatenated list of features, which could then be
interpolated into a suitable sales-pitch:
.Sp
.Vb 3
\&    Shimmer is the Multi\-purpose Time\-saving Easy\-to\-use
\&    Long\-lasting Non\-toxic Polymer\-based Low\-carb Non\-dairy
\&    Sugar\-free alternative!
.Ve
.Sp
It's also possible to specify a set of cumulative methods that
start at the base class(es) of the hierarchy and work downwards, the way
\&\s-1\fIBUILD\s0()\fR does. To get that effect, you simply mark each method with
:CUMULATIVE(\s-1BASE FIRST\s0), instead of just :CUMULATIVE. For example:
.Sp
.Vb 7
\&    package Wax::Floor;
\&    use Class::Std;
\&    {
\&        sub active_ingredients :CUMULATIVE(BASE FIRST) {
\&            return "\etparadichlorobenzene, cyanoacrylate, peanuts\en";
\&        }
\&    }
\&
\&    package Topping::Dessert;
\&    use Class::Std;
\&    {
\&        sub active_ingredients :CUMULATIVE(BASE FIRST) {
\&            return "\etsodium hypochlorite, isobutyl ketone, ethylene glycol\en";
\&        }
\&    }
\&
\&    package Shimmer;
\&    use Class::Std;
\&    use base qw( Wax::Floor  Topping::Dessert );
\&
\&    {
\&        sub active_ingredients :CUMULATIVE(BASE FIRST) {
\&            return "\etaromatic hydrocarbons, xylene, methyl mercaptan\en";
\&        }
\&    }
.Ve
.Sp
So a scalar-context call to \fIactive_ingredients()\fR:
.Sp
.Vb 2
\&    my $ingredients = Shimmer\->active_ingredients();
\&    print "May contain trace amounts of:\en$ingredients";
.Ve
.Sp
would start in the base classes and work downwards, concatenating base\-
class ingredients before those of the derived class, to produce:
.Sp
.Vb 4
\&    May contain trace amounts of:
\&        paradichlorobenzene, cyanoacrylate, peanuts
\&        sodium hypochlorite, isobutyl ketone, ethylene glycol
\&        aromatic hydrocarbons, xylene, methyl mercaptan
.Ve
.Sp
Or, you could treat the return value as a hash:
.Sp
.Vb 1
\&    print Data::Dumper::Dumper \e%{$ingredients};
.Ve
.Sp
and see which ingredients came from where:
.Sp
.Vb 3
\&    $VAR1 = {
\&       \*(AqShimmer\*(Aq
\&            => \*(Aqaromatic hydrocarbons, xylene, methyl mercaptan\*(Aq,
\&
\&       \*(AqTopping::Dessert\*(Aq
\&            => \*(Aqsodium hypochlorite, isobutyl ketone, ethylene glycol\*(Aq,
\&
\&        \*(AqWax::Floor\*(Aq
\&            => \*(AqWax: paradichlorobenzene,  hydrogen peroxide, cyanoacrylate\*(Aq,
\&    };
.Ve
.Sp
Note that you can't specify both \f(CW\*(C`:CUMULATIVE\*(C'\fR and \f(CW\*(C`:CUMULATIVE(BASE
FIRST)\*(C'\fR on methods of the same name in the same hierarchy. The resulting
set of methods would have no well-defined invocation order, so
Class::Std throws a compile-time exception instead.
.ie n .IP """:STRINGIFY""" 4
.el .IP "\f(CW:STRINGIFY\fR" 4
.IX Item ":STRINGIFY"
If you define a method and add the \f(CW\*(C`:STRINGIFY\*(C'\fR marker then that method
is used whenever an object of the corresponding class needs to be
coerced to a string. In other words, instead of:
.Sp
.Vb 4
\&    # Convert object to a string...
\&    sub as_str {
\&        ...
\&    }
\&
\&    # Convert object to a string automatically in string contexts...
\&    use overload (
\&        q{""}    => \*(Aqas_str\*(Aq,
\&        fallback => 1,
\&    );
.Ve
.Sp
you can just write:
.Sp
.Vb 4
\&    # Convert object to a string (automatically in string contexts)...
\&    sub as_str : STRINGIFY {
\&        ...
\&    }
.Ve
.ie n .IP """:NUMERIFY""" 4
.el .IP "\f(CW:NUMERIFY\fR" 4
.IX Item ":NUMERIFY"
If you define a method and add the \f(CW\*(C`:NUMERIFY\*(C'\fR marker then that method
is used whenever an object of the corresponding class needs to be
coerced to a number. In other words, instead of:
.Sp
.Vb 4
\&    # Convert object to a number...
\&    sub as_num {
\&        ...
\&    }
\&
\&    # Convert object to a string automatically in string contexts...
\&    use overload (
\&        q{0+}    => \*(Aqas_num\*(Aq,
\&        fallback => 1,
\&    );
.Ve
.Sp
you can just write:
.Sp
.Vb 4
\&    # Convert object to a number (automatically in numeric contexts)...
\&    sub as_num : NUMERIFY {
\&        ...
\&    }
.Ve
.ie n .IP """:BOOLIFY""" 4
.el .IP "\f(CW:BOOLIFY\fR" 4
.IX Item ":BOOLIFY"
If you define a method and add the \f(CW\*(C`:BOOLIFY\*(C'\fR marker then that method
is used whenever an object of the corresponding class needs to be
coerced to a boolean value. In other words, instead of:
.Sp
.Vb 4
\&    # Convert object to a boolean...
\&    sub as_bool {
\&        ...
\&    }
\&
\&    # Convert object to a boolean automatically in boolean contexts...
\&    use overload (
\&        q{bool}    => \*(Aqas_bool\*(Aq,
\&        fallback => 1,
\&    );
.Ve
.Sp
you can just write:
.Sp
.Vb 4
\&    # Convert object to a boolean (automatically in boolean contexts)...
\&    sub as_bool : BOOLIFY {
\&        ...
\&    }
.Ve
.ie n .IP """:SCALARIFY""" 4
.el .IP "\f(CW:SCALARIFY\fR" 4
.IX Item ":SCALARIFY"
.PD 0
.ie n .IP """:ARRAYIFY""" 4
.el .IP "\f(CW:ARRAYIFY\fR" 4
.IX Item ":ARRAYIFY"
.ie n .IP """:HASHIFY""" 4
.el .IP "\f(CW:HASHIFY\fR" 4
.IX Item ":HASHIFY"
.ie n .IP """:GLOBIFY""" 4
.el .IP "\f(CW:GLOBIFY\fR" 4
.IX Item ":GLOBIFY"
.ie n .IP """:CODIFY""" 4
.el .IP "\f(CW:CODIFY\fR" 4
.IX Item ":CODIFY"
.PD
If a method is defined with one of these markers, then it is automatically
called whenever an object of that class is treated as a reference of the
corresponding type.
.Sp
For example, instead of:
.Sp
.Vb 2
\&    sub as_hash {
\&        my ($self) = @_;
\&
\&        return {
\&            age      => $age_of{ident $self},
\&            shoesize => $shoe_of{ident $self},
\&        };
\&    }
\&
\&    use overload (
\&        \*(Aq%{}\*(Aq    => \*(Aqas_hash\*(Aq,
\&        fallback => 1,
\&    );
.Ve
.Sp
you can just write:
.Sp
.Vb 2
\&    sub as_hash : HASHIFY {
\&        my ($self) = @_;
\&
\&        return {
\&            age      => $age_of{ident $self},
\&            shoesize => $shoe_of{ident $self},
\&        };
\&    }
.Ve
.Sp
Likewise for methods that allow an object to be treated as a scalar
reference (\f(CW\*(C`:SCALARIFY\*(C'\fR), a array reference (\f(CW\*(C`:ARRAYIFY\*(C'\fR), a
subroutine reference (\f(CW\*(C`:CODIFY\*(C'\fR), or a typeglob reference
(\f(CW\*(C`:GLOBIFY\*(C'\fR).
.SH "DIAGNOSTICS"
.IX Header "DIAGNOSTICS"
.ie n .IP "Can't find class %s" 4
.el .IP "Can't find class \f(CW%s\fR" 4
.IX Item "Can't find class %s"
You tried to call the \fIClass::Std::new()\fR constructor on a class 
that isn't built using Class::Std. Did you forget to write \f(CW\*(C`use Class::Std\*(C'\fR
after the package declaration?
.ie n .IP "Argument to %s\->\fInew()\fR must be hash reference" 4
.el .IP "Argument to \f(CW%s\fR\->\fInew()\fR must be hash reference" 4
.IX Item "Argument to %s->new() must be hash reference"
The constructors created by Class::Std require all initializer values
to be passed in a hash, but you passed something that wasn't a hash.
Put your constructor arguments in a hash.
.ie n .IP "Missing initializer label for %s: %s" 4
.el .IP "Missing initializer label for \f(CW%s:\fR \f(CW%s\fR" 4
.IX Item "Missing initializer label for %s: %s"
You specified that one or more attributes had initializer values (using the
\&\f(CW\*(C`init\*(C'\fR argument inside the attribute's \f(CW\*(C`ATTR\*(C'\fR marker), but then failed
to pass in the corresponding initialization value. Often this happens because
the initialization value \fIwas\fR passed, but the key specifying the
attribute name was misspelled.
.IP "Can't make anonymous subroutine cumulative" 4
.IX Item "Can't make anonymous subroutine cumulative"
You attempted to use the \f(CW\*(C`:CUMULATIVE\*(C'\fR marker on an anonymous subroutine.
But that marker can only be applied to the named methods of a class. Convert
the anonymous subroutine to a named subroutine, or find some other way to 
make it interoperate with other methods.
.ie n .IP "Conflicting definitions for cumulative method: %s" 4
.el .IP "Conflicting definitions for cumulative method: \f(CW%s\fR" 4
.IX Item "Conflicting definitions for cumulative method: %s"
You defined a \f(CW\*(C`:CUMULATIVE\*(C'\fR and a \f(CW\*(C`:CUMULATIVE(BASE FIRST)\*(C'\fR method of the
same name in two classes within the same hierarchy. Since methods can only be
called going strictly up through the hierarchy or going strictly down 
through the hierarchy, specifying both directions is obviously a mistake.
Either rename one of the methods, or decide whether they should accumulate
upwards or downwards.
.IP "Missing new value in call to 'set_%s' method" 4
.IX Item "Missing new value in call to 'set_%s' method"
You called an attribute setter method without providing a new value 
for the attribute. Often this happens because you passed an array that
happened to be empty. Make sure you pass an actual value.
.ie n .IP "Can't locate %s method ""%s"" via package %s" 4
.el .IP "Can't locate \f(CW%s\fR method ``%s'' via package \f(CW%s\fR" 4
.IX Item "Can't locate %s method %s via package %s"
You attempted to call a method on an object but no such method is defined
anywhere in the object's class hierarchy. Did you misspell the method name, or
perhaps misunderstand which class the object belongs to?
.ie n .IP "%s method %s declared but not defined" 4
.el .IP "\f(CW%s\fR method \f(CW%s\fR declared but not defined" 4
.IX Item "%s method %s declared but not defined"
A method was declared with a \f(CW\*(C`:RESTRICTED\*(C'\fR or \f(CW\*(C`:PRIVATE\*(C'\fR, like so:
.Sp
.Vb 2
\&    sub foo :RESTRICTED;
\&    sub bar :PRIVATE;
.Ve
.Sp
But the actual subroutine was not defined by the end of the compilation
phase, when the module needed it so it could be rewritten to restrict or
privatize it.
.ie n .IP "Can't call restricted method %s from class %s" 4
.el .IP "Can't call restricted method \f(CW%s\fR from class \f(CW%s\fR" 4
.IX Item "Can't call restricted method %s from class %s"
The specified method was declared with a \f(CW\*(C`:RESTRICTED\*(C'\fR marker but
subsequently called from outside its class hierarchy. Did you call the
wrong method, or the right method from the wrong place?
.ie n .IP "Can't call private method %s from class %s" 4
.el .IP "Can't call private method \f(CW%s\fR from class \f(CW%s\fR" 4
.IX Item "Can't call private method %s from class %s"
The specified method was declared with a \f(CW\*(C`:PRIVATE\*(C'\fR marker but
subsequently called from outside its own class. Did you call the wrong
method, or the right method from the wrong place?
.ie n .IP "Internal error: %s" 4
.el .IP "Internal error: \f(CW%s\fR" 4
.IX Item "Internal error: %s"
Your code is okay, but it uncovered a bug in the Class::Std module.
\&\*(L"\s-1BUGS AND LIMITATIONS\*(R"\s0 explains how to report the problem.
.SH "CONFIGURATION AND ENVIRONMENT"
.IX Header "CONFIGURATION AND ENVIRONMENT"
Class::Std requires no configuration files or environment variables.
.SH "DEPENDENCIES"
.IX Header "DEPENDENCIES"
Class::Std depends on the following modules:
.IP "\(bu" 4
version
.IP "\(bu" 4
Scalar::Util
.IP "\(bu" 4
Data::Dumper
.SH "INCOMPATIBILITIES"
.IX Header "INCOMPATIBILITIES"
Incompatible with the Attribute::Handlers module, since both define
meta-attributes named :ATTR.
.SH "BUGS AND LIMITATIONS"
.IX Header "BUGS AND LIMITATIONS"
.IP "\(bu" 4
Does not handle threading (including \f(CW\*(C`fork()\*(C'\fR under Windows).
.IP "\(bu" 4
\&\f(CW\*(C`:ATTR\*(C'\fR declarations must all be on the same line (due to a limitation in
Perl itself).
.IP "\(bu" 4
\&\f(CW\*(C`:ATTR\*(C'\fR declarations cannot include variables, since these are not
interpolated into the declaration (a limitation in Perl itself).
.PP
Please report any bugs or feature requests to
\&\f(CW\*(C`bug\-class\-std@rt.cpan.org\*(C'\fR, or through the web interface at
<http://rt.cpan.org>.
.SH "ALTERNATIVES"
.IX Header "ALTERNATIVES"
Inside-out objects are gaining in popularity and there are now many other
modules that implement frameworks for building inside-out classes. These
include:
.IP "Object::InsideOut" 4
.IX Item "Object::InsideOut"
Array-based objects, with support for threading. Many excellent features
(especially thread-safety), but slightly less secure than Class::Std,
due to non-encapsulation of attribute data addressing.
.IP "Class::InsideOut" 4
.IX Item "Class::InsideOut"
A minimalist approach to building inside-out classes.
.IP "Lexical::Attributes" 4
.IX Item "Lexical::Attributes"
Uses source filters to provide a near-Perl 6 approach to declaring inside-out
classes.
.IP "Class::Std::Storable" 4
.IX Item "Class::Std::Storable"
Adds serialization/deserialization to Class::Std.
.SH "AUTHOR"
.IX Header "AUTHOR"
Damian Conway  \f(CW\*(C`<DCONWAY@cpan.org>\*(C'\fR
.SH "LICENCE AND COPYRIGHT"
.IX Header "LICENCE AND COPYRIGHT"
Copyright (c) 2005, Damian Conway \f(CW\*(C`<DCONWAY@cpan.org>\*(C'\fR. All rights reserved.
.PP
Portions of the documentation from \*(L"Perl Best Practices\*(R" copyright (c)
2005 by O'Reilly Media, Inc. and reprinted with permission.
.PP
This module is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
.SH "DISCLAIMER OF WARRANTY"
.IX Header "DISCLAIMER OF WARRANTY"
\&\s-1BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE SOFTWARE \*(L"AS IS\*(R" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH
YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
NECESSARY SERVICING, REPAIR, OR CORRECTION.\s0
.PP
\&\s-1IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENCE, BE
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
THE SOFTWARE \s0(\s-1INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE\s0), \s-1EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.\s0