1Class::Std(3) User Contributed Perl Documentation Class::Std(3)
2
6 Class::Std - Support for creating standard "inside-out" classes
7
9 This document describes Class::Std version 0.013
10
12 package MyClass;
13 use Class::Std;
14 # Create storage for object attributes...
16 my %name : ATTR;
17 my %rank : ATTR;
18 my %snum : ATTR;
19 my %public_data : ATTR;
21 # Handle initialization of objects of this class...
23 sub BUILD {
24 my ($self, $obj_ID, $arg_ref) = @_;
25 $name{$obj_ID} = check_name( $arg_ref->{name} );
27 $rank{$obj_ID} = check_rank( $arg_ref->{rank} );
28 $snum{$obj_ID} = _gen_uniq_serial_num();
29 }
30 # Handle cleanup of objects of this class...
32 sub DEMOLISH {
33 my ($self, $obj_ID) = @_;
34 _recycle_serial_num( $snum{$obj_ID} );
36 }
37 # Handle unknown method calls...
39 sub AUTOMETHOD {
40 my ($self, $obj_ID, @other_args) = @_;
41 # Return any public data...
43 if ( m/\A get_(.*)/ ) { # Method name passed in $_
44 my $get_what = $1;
45 return sub {
46 return $public_data{$obj_ID}{$get_what};
47 }
48 }
49 warn "Can't call $method_name on ", ref $self, " object";
51 return; # The call is declined by not returning a sub ref
53 }
54
56 This module provides tools that help to implement the "inside out
57 object" class structure in a convenient and standard way.
58 Portions of the following code and documentation from "Perl Best
60 Practices" copyright (c) 2005 by O'Reilly Media, Inc. and reprinted
61 with permission.
62 Introduction
64 Most programmers who use Perl's object-oriented features construct
65 their objects by blessing a hash. But, in doing so, they undermine the
66 robustness of the OO approach. Hash-based objects are unencapsulated:
67 their entries are open for the world to access and modify.
68 Objects without effective encapsulation are vulnerable. Instead of
70 politely respecting their public interface, some clever client coder
71 inevitably will realize that it's marginally faster to interact
72 directly with the underlying implementation, pulling out attribute
73 values directly from the hash of an object:
74 for my $file ( get_file_objs() ) {
76 print $file->{name}, "\n";
77 }
78 instead of using the official interface:
80 for my $file ( get_file_objs() ) {
82 print $file->get_name(), "\n";
83 }
84 From the moment someone does that, your class is no longer cleanly
86 decoupled from the code that uses it. You can't be sure that any bugs
87 in your class are actually caused by the internals of your class, and
88 not the result of some kind of monkeying by the client code. And to
89 make matters worse, now you can't ever change those internals without
90 the risk of breaking some other part of the system.
91 There is a simple, convenient, and utterly secure way to prevent client
93 code from accessing the internals of the objects you provide. Happily,
94 that approach also guards against misspelling attribute names (a common
95 error in hash-based classes), as well as being just as fast as--and
96 often more memory-efficient than--ordinary hash-based objects.
97 That approach is referred to by various names--flyweight scalars,
99 warehoused attributes, inverted indices--but most commonly it's known
100 as: inside-out objects. Consider the following class definitions:
101 package File::Hierarchy;
103 {
104 # Objects of this class have the following attributes...
105 my %root_of; # The root directory of the file hierarchy
106 my %files_of; # Array storing object for each file in root directory
107 # Constructor takes path of file system root directory...
109 sub new {
110 my ($class, $root) = @_;
111 # Bless a scalar to instantiate the new object...
113 my $new_object = bless \do{my $anon_scalar}, $class;
114 # Initialize the object's "root" attribute...
116 $root_of{ident $new_object} = $root;
117 return $new_object;
119 }
120 # Retrieve files from root directory...
122 sub get_files {
123 my ($self) = @_;
124 # Load up the "files" attribute, if necessary...
126 if (!exists $files_of{ident $self}) {
127 $files_of{ident $self}
128 = File::System->list_files($root_of{ident $self});
129 }
130 # Flatten the "files" attribute's array to produce a file list...
132 return @{ $files_of{ident $self} };
133 }
134 }
135 package File::Hierarchy::File;
137 {
138 # Objects of this class have the following attributes...
139 my %name_of; # the name of the file
140 # Constructor takes name of file...
142 sub new {
143 my ($class, $filename) = @_;
144 # Bless a scalar to instantiate the new object...
146 my $new_object = bless \do{my $anon_scalar}, $class;
147 # Initialize the object's "name" attribute...
149 $name_of{ident $new_object} = $filename;
150 return $new_object;
152 }
153 # Retrieve name of file...
155 sub get_name {
156 my ($self) = @_;
157 return $name_of{ident $self};
159 }
160 }
161 Unlike a hash-based class, each of these inside-out class is specified
163 inside a surrounding code block:
164 package File::Hierarchy;
166 {
167 # [Class specification here]
168 }
169 package File::Hierarchy::File;
171 {
172 # [Class specification here]
173 }
174 That block is vital, because it creates a limited scope, to which any
176 lexical variables that are declared as part of the class will
177 automatically be restricted.
178 The next difference between the two versions of the classes is that
180 each attribute of all the objects in the class is now stored in a
181 separate single hash:
182 # Objects of this class have the following attributes...
184 my %root_of; # The root directory of the file hierarchy
186 my %files_of; # Array storing object for each file in root directory
187 This is 90 degrees to the usual hash-based approach. In hash-based
189 classes, all the attributes of one object are stored in a single hash;
190 in inside-out classes, one attribute from all objects is stored in a
191 single hash. Diagrammatically:
192 Hash-based:
194 Attribute 1 Attribute 2
195 Object A { attr1 => $valA1, attr2 => $val2 }
197 Object B { attr1 => $valB1, attr2 => $val2 }
199 Object C { attr1 => $valB1, attr2 => $val2 }
201 Inside-out:
205 Object A Object B Object C
206 Attribute 1 { 19817 => $valA1, 172616 => $valB1, 67142 => $valC1 }
208 Attribute 2 { 19817 => $valA2, 172616 => $valB2, 67142 => $valC3 }
210 Attribute 3 { 19817 => $valA3, 172616 => $valB3, 67142 => $valC3 }
212 So the attributes belonging to each object are distributed across a set
214 of predeclared hashes, rather than being squashed together into one
215 anonymous hash.
216 This is a significant improvement. By telling Perl what attributes you
218 expect to use, you enable the compiler to check--via use strict--that
219 you do indeed use only those attributes.
220 That's because of the third difference in the two approaches. Each
222 attribute of a hash-based object is stored in an entry in the object's
223 hash: "$self->{name}". In other words, the name of a hash-based
224 attribute is symbolic: specified by the string value of a hash key. In
225 contrast, each attribute of an inside-out object is stored in an entry
226 of the attribute's hash: $name_of{ident $self}. So the name of an
227 inside-out attribute isn't symbolic; it's a hard-coded variable name.
228 With hash-based objects, if an attribute name is accidentally
230 misspelled in some method:
231 sub set_name {
233 my ($self, $new_name) = @_;
234 $self->{naem} = $new_name; # Oops!
236 return;
238 }
239 then the $self hash will obligingly--and silently!--create a new entry
241 in the hash, with the key 'naem', then assign the new name to it. But
242 since every other method in the class correctly refers to the attribute
243 as "$self-"{name}>, assigning the new value to "$self-"{naem}>
244 effectively makes that assigned value "vanish".
245 With inside-out objects, however, an object's "name" attribute is
247 stored as an entry in the class's lexical %name_of hash. If the
248 attribute name is misspelled then you're attempting to refer to an
249 entirely different hash: %naem_of. Like so:
250 sub set_name {
252 my ($self, $new_name) = @_;
253 $naem_of{ident $self} = $new_name; # Kaboom!
255 return;
257 }
258 But, since there's no such hash declared in the scope, use strict will
260 complain (with extreme prejudice):
261 Global symbol "%naem_of" requires explicit package name at Hierarchy.pm line 86
263 Not only is that consistency check now automatic, it's also performed
265 at compile time.
266 The next difference is even more important and beneficial. Instead of
268 blessing an empty anonymous hash as the new object:
269 my $new_object = bless {}, $class;
271 the inside-out constructor blesses an empty anonymous scalar:
273 my $new_object = bless \do{my $anon_scalar}, $class;
275 That odd-looking "\do{my $anon_scalar}" construct is needed because
277 there's no built-in syntax in Perl for creating a reference to an
278 anonymous scalar; you have to roll-your-own.
279 The anonymous scalar is immediately passed to bless, which anoints it
281 as an object of the appropriate class. The resulting object reference
282 is then stored in $new_object.
283 Once the object exists, it's used to create a unique key ("ident
285 $new_object") under which each attribute that belongs to the object
286 will be stored (e.g. $root_of{ident $new_object} or $name_of{ident
287 $self}). The ident() utility that produces this unique key is provided
288 by the Class::Std module and is identical in effect to the refaddr()
289 function in the standard Scalar::Util module.
290 To recap: every inside-out object is a blessed scalar, and
292 has--intrinsic to it--a unique identifying integer. That integer can be
293 obtained from the object reference itself, and then used to access a
294 unique entry for the object in each of the class's attribute hashes.
295 This means that every inside-out object is nothing more than an
297 unintialized scalar. When your constructor passes a new inside-out
298 object back to the client code, all that comes back is an empty scalar,
299 which makes it impossible for that client code to gain direct access to
300 the object's internal state.
301 Of the several popular methods of reliably enforcing encapsulation in
303 Perl, inside-out objects are also by far the cheapest. The run-time
304 performance of inside-out classes is effectively identical to that of
305 regular hash-based classes. In particular, in both schemes, every
306 attribute access requires only a single hash look-up. The only
307 appreciable difference in speed occurs when an inside-out object is
308 destroyed.
309 Hash-based classes usually don't even have destructors. When the
311 object's reference count decrements to zero, the hash is automatically
312 reclaimed, and any data structures stored inside the hash are likewise
313 cleaned up. This works so well that many OO Perl programmers find they
314 never need to write a DESTROY() method; Perl's built-in garbage
315 collection handles everything just fine. In fact, the only time a
316 destructor is needed is when objects have to manage resources outside
317 that are not actually located inside the object, resources that need to
318 be separately deallocated.
319 But the whole point of an inside-out object is that its attributes are
321 stored in allocated hashes that are not actually located inside the
322 object. That's precisely how it achieves secure encapsulation: by not
323 sending the attributes out into the client code.
324 Unfortunately, that means when an inside-out object is eventually
326 garbage collected, the only storage that is reclaimed is the single
327 blessed scalar implementing the object. The object's attributes are
328 entirely unaffected by the object's deallocation, because the
329 attributes are not inside the object, nor are they referred to by it in
330 any way.
331 Instead, the attributes are referred to by the various attribute hashes
333 in which they're stored. And since those hashes will continue to exist
334 until the end of the program, the defunct object's orphaned attributes
335 will likewise continue to exist, safely nestled inside their respective
336 hashes, but now untended by any object. In other words, when an inside-
337 out object dies, its associated attribute hashes leak memory.
338 The solution is simple. Every inside-out class has to provide a
340 destructor that "manually" cleans up the attributes of the object being
341 destructed:
342 package File::Hierarchy;
344 {
345 # Objects of this class have the following attributes...
346 my %root_of; # The root directory of the file hierarchy
347 my %files_of; # Array storing object for each file in root directory
348 # Constructor takes path of file system root directory...
350 sub new {
351 # As before
352 }
353 # Retrieve files from root directory...
355 sub get_files {
356 # As before
357 }
358 # Clean up attributes when object is destroyed...
360 sub DESTROY {
361 my ($self) = @_;
362 delete $root_of{ident $self};
364 delete $files_of{ident $self};
365 }
366 }
367 The obligation to provide a destructor like this in every inside-out
369 class can be mildly irritating, but it is still a very small price to
370 pay for the considerable benefits that the inside-out approach
371 otherwise provides for free. And the irritation can easily be
372 eliminated by using the appropriate class construction tools. See
373 below.
374 Automating Inside-Out Classes
376 Perhaps the most annoying part about building classes in Perl (no
377 matter how the objects are implemented) is that the basic structure of
378 every class is more or less identical. For example, the implementation
379 of the "File::Hierarchy::File" class used in "File::Hierarchy" looks
380 like this:
381 package File::Hierarchy::File;
383 {
384 # Objects of this class have the following attributes...
385 my %name_of; # the name of the file
386 # Constructor takes name of file...
388 sub new {
389 my ($class, $filename) = @_;
390 # Bless a scalar to instantiate the new object...
392 my $new_object = bless \do{my $anon_scalar}, $class;
393 # Initialize the object's "name" attribute...
395 $name_of{ident $new_object} = $filename;
396 return $new_object;
398 }
399 # Retrieve name of file...
401 sub get_name {
402 my ($self) = @_;
403 return $name_of{ident $self};
405 }
406 # Clean up attributes when object is destroyed...
408 sub DESTROY {
409 my ($self) = @_;
410 delete $name_of{ident $self};
412 }
413 }
414 Apart from the actual names of the attributes, and their accessor
416 methods, that's exactly the same structure, and even the same code, as
417 in the "File::Hierarchy" class.
418 Indeed, the standard infrastructure of every inside-out class looks
420 exactly the same. So it makes sense not to have to rewrite that
421 standard infrastructure code in every separate class.
422 That's precisely what this module does: it implements the necessary
424 infrastructure for inside-out objects. See below.
425
427 Exported subroutines
428 ident()
429 Class::Std always exports a subroutine called ident(). This
430 subroutine returns a unique integer ID for any object passed to it.
431 Non-exported subroutines
433 Class::Std::initialize()
434 This subroutine sets up all the infrastructure to support your
435 Class::Std- based class. It is usually called automatically in a
436 "CHECK" block, or (if the "CHECK" block fails to run -- under
437 "mod_perl" or "require Class::Std" or "eval "..."") during the
438 first constructor call made to a Class::Std-based object.
439 In rare circumstances, you may need to call this subroutine
441 directly yourself. Specifically, if you set up cumulative,
442 restricted, private, or automethodical class methods (see below),
443 and call any of them before you create any objects, then you need
444 to call Class::Std::initialize() first.
445 Methods created automatically
447 The following subroutines are installed in any class that uses the
448 Class::Std module.
449 new()
451 Every class that loads the Class::Std module automatically has a
452 new() constructor, which returns an inside-out object (i.e. a
453 blessed scalar).
454 $obj = MyClass->new();
456 The constructor can be passed a single argument to initialize the
458 object. This argument must be a hash reference.
459 $obj = MyClass->new({ name=>'Foo', location=>'bar' });
461 See the subsequent descriptions of the BUILD() and START() methods
463 and :ATTR() trait, for an explanation of how the contents of this
464 optional hash can be used to initialize the object.
465 It is almost always an error to implement your own new() in any
467 class that uses Class::Std. You almost certainly want to write a
468 BUILD() or START() method instead. See below.
469 DESTROY()
471 Every class that loads the Class::Std module automatically has a
472 DESTROY() destructor, which automatically cleans up any attributes
473 declared with the :ATTR() trait (see below).
474 It is almost always an error to write your own DESTROY() in any
476 class that uses Class::Std. You almost certainly want to write your
477 own DEMOLISH() instead. See below.
478 AUTOLOAD()
480 Every class that loads the Class::Std module automatically has an
481 AUTOLOAD() method, which implements the AUTOMETHOD() mechanism
482 described below.
483 It is almost always an error to write your own AUTOLOAD() in any
485 class that uses Class::Std. You almost certainly want to write your
486 own AUTOMETHOD() instead.
487 _DUMP()
489 This method returns a string that represents the internal state
490 (i.e. the attribute values) of the object on which it's called.
491 Only those attributes which are marked with an ":ATTR" (see below)
492 are reported. Attribute names are reported only if they can be
493 ascertained from an ":init_arg", ":get", or ":set" option within
494 the :ATTR().
495 Note that _DUMP() is not designed to support full
497 serialization/deserialization of objects. See the separate
498 Class::Std::Storable module (on CPAN) for that.
499 Methods that can be supplied by the developer
501 The following subroutines can be specified as standard methods of a
502 Class::Std class.
503 BUILD()
505 When the new() constructor of a Class::Std class is called, it
506 automatically calls every method named BUILD() in all the classes
507 in the new object's hierarchy. That is, when the constructor is
508 called, it walks the class's inheritance tree (from base classes
509 downwards) and calls every BUILD() method it finds along the way.
510 This means that, to initialize any class, you merely need to
512 provide a BUILD() method for that class. You don't have to worry
513 about ensuring that any ancestral BUILD() methods also get called;
514 the constructor will take care of that.
515 Each BUILD() method is called with three arguments: the invocant
517 object, the identifier number of that object, and a reference to (a
518 customized version of) the hash of arguments that was originally
519 passed to the constructor:
520 sub BUILD {
522 my ($self, $ident, $args_ref) = @_;
523 ...
524 }
525 The argument hash is a "customized version" because the module
527 automatically does some fancy footwork to ensure that the arguments
528 are the ones appropriate to the class itself. That's because
529 there's a potential for collisions when Class::Std classes are used
530 in a hierarchy.
531 One of the great advantages of using inside-out classes instead of
533 hash-based classes is that an inside-out base class and an inside-
534 out derived class can then each have an attribute of exactly the
535 same name, which are stored in separate lexical hashes in separate
536 scopes. In a hash-based object that's impossible, because the
537 single hash can't have two attributes with the same key.
538 But that very advantage also presents something of a problem when
540 constructor arguments are themselves passed by hash. If two or more
541 classes in the name hierarchy do happen to have attributes of the
542 same name, the constructor will need two or more initializers with
543 the name key. Which a single hash can't provide.
544 The solution is to allow initializer values to be partitioned into
546 distinct sets, each uniquely named, and which are then passed to
547 the appropriate base class. The easiest way to accomplish that is
548 to pass in a hash of hashes, where each top level key is the name
549 of one of the base classes, and the corresponding value is a hash
550 of initializers specifically for that base class.
551 For example:
553 package Client;
555 use Class::Std::Utils;
556 {
557 my %client_num_of :ATTR; # Every client has a basic ID number
558 my %name_of :ATTR;
559 sub BUILD {
561 my ($self, $ident, $arg_ref) = @_;
562 $client_num_of{$ident} = $arg_ref->{'Client'}{client_num};
564 $name_of{$ident} = $arg_ref->{'Client'}{client_name};
565 }
566 }
567 package Client::Corporate;
569 use base qw( Client );
570 use Class::Std::Utils;
571 {
572 my %client_num_of; # Corporate clients have an additional ID number
573 my %corporation_of;
574 my %position_of;
575 sub BUILD {
577 my ($self, $ident, $arg_ref) = @_;
578 $client_num_of{$ident}
580 = $arg_ref->{'Client::Corporate'}{client_num};
581 $corporation_of{$ident}
582 = $arg_ref->{'Client::Corporate'}{corp_name};
583 $position_of{$ident}
584 = $arg_ref->{'Client::Corporate'}{position};
585 }
586 }
587 # and later...
589 my $new_client
591 = Client::Corporate->new( {
592 'Client' => {
593 client_num => '124C1',
594 client_name => 'Humperdinck',
595 },
596 'Client::Corporate' => {
597 client_num => 'F_1692',
598 corp_name => 'Florin',
599 position => 'CEO',
600 },
601 });
602 Now each class's BUILD() method picks out only the initializer sub-
604 hash whose key is that class's own name. Since every class name is
605 different, the top-level keys of this multi-level initializer hash
606 are guaranteed to be unique. And since no single class can have two
607 identically named attributes, the keys of each second-level hash
608 will be unique as well. If two classes in the hierarchy both need
609 an initializer of the same name (e.g. 'client_num'), those two hash
610 entries will now be in separate sub-hashes, so they will never
611 clash.
612 Class::Std provides an even more sophisticated variation on this
614 functionality, which is generally much more convenient for the
615 users of classes. Classes that use Class::Std infrastructure allow
616 both general and class-specific initializers in the initialization
617 hash. Clients only need to specify classes for those initializers
618 whose names actually are ambiguous. Any other arguments can just be
619 passed directly in the top-level hash:
620 my $new_client
622 = Client::Corporate->new( {
623 client_name => 'Humperdinck',
624 corp_name => 'Florin',
625 position => 'CEO',
626 'Client' => { client_num => '124C1' },
628 'Client::Corporate' => { client_num => 'F_1692' },
629 });
630 Class::Std also makes it easy for each class's BUILD() to access
632 these class-specific initializer values. Before each BUILD() is
633 invoked, the nested hash whose key is the same as the class name is
634 flattened back into the initializer hash itself. That is,
635 Client::BUILD() is passed the hash:
636 {
638 client_name => 'Humperdinck',
639 corp_name => 'Florin',
640 position => 'CEO',
641 client_num => '124C1', # Flattened from 'Client' nested subhash
642 'Client' => { client_num => '124C1' },
644 'Client::Corporate' => { client_num => 'F_1692' },
645 }
646 whereas Client::Corporate::BUILD() is passed the hash:
648 {
650 client_name => 'Humperdinck',
651 corp_name => 'Florin',
652 position => 'CEO',
653 client_num => 'F_1692', # Flattened from 'Client::Corporate' subhash
654 'Client' => { client_num => '124C1' },
656 'Client::Corporate' => { client_num => 'F_1692' },
657 }
658 This means that the BUILD() method for each class can just assume
660 that the correct class-specific initializer values will available
661 at the top level of the hash. For example:
662 sub Client::BUILD {
664 my ($self, $ident, $arg_ref) = @_;
665 $client_num_of{$ident} = $arg_ref->{client_num}; # '124C1'
667 $name_of{$ident} = $arg_ref->{client_name};
668 }
669 sub Client::Corporate::BUILD {
671 my ($self, $ident, $arg_ref) = @_;
672 $client_num_of{$ident} = $arg_ref->{client_num}; # 'F_1692'
674 $corporation_of{$ident} = $arg_ref->{corp_name};
675 $position_of{$ident} = $arg_ref->{position};
676 }
677 Both classes use the "$arg_ref->{client_num}" initializer value,
679 but Class::Std automatically arranges for that value to be the
680 right one for each class.
681 Also see the :ATTR() marker (described below) for a simpler way of
683 initializing attributes.
684 START()
686 Once all the BUILD() methods of a class have been called and any
687 initialization values or defaults have been subsequently applied to
688 uninitialized attributes, Class::Std arranges for any START()
689 methods in the class's hierarchy to be called befre the constructor
690 finishes. That is, after the build and default initialization
691 processes are complete, the constructor walks down the class's
692 inheritance tree a second time and calls every START() method it
693 finds along the way.
694 As with BUILD(), each START() method is called with three
696 arguments: the invocant object, the identifier number of that
697 object, and a reference to (a customized version of) the hash of
698 arguments that was originally passed to the constructor.
699 The main difference between a BUILD() method and a START() method
701 is that a BUILD() method runs before any attribute of the class is
702 auto-initialized or default-initialized, whereas a START() method
703 runs after all the attributes of the class (including attributes in
704 derived classes) have been initialized in some way. So if you want
705 to pre-empt the initialization process, write a BUILD(). But if you
706 want to do something with the newly created and fully initialized
707 object, write a START() instead. Of course, any class can define
708 both a BUILD() and a START() method, if that happens to be
709 appropriate.
710 DEMOLISH()
712 The DESTROY() method that is automatically provided by Class::Std
713 ensures that all the marked attributes (see the :ATTR() marker
714 below) of an object, from all the classes in its inheritance
715 hierarchy, are automatically cleaned up.
716 But, if a class requires other destructor behaviours (e.g. closing
718 filehandles, decrementing allocation counts, etc.) then you may
719 need to specify those explicitly.
720 Whenever an object of a Class::Std class is destroyed, the
722 DESTROY() method supplied by Class::Std automatically calls every
723 method named DEMOLISH() in all the classes in the new object's
724 hierarchy. That is, when the destructor is called, it walks the
725 class's inheritance tree (from derived classes upwards) and calls
726 every DEMOLISH() method it finds along the way.
727 This means that, to clean up any class, you merely need to provide
729 a DEMOLISH() method for that class. You don't have to worry about
730 ensuring that any ancestral DEMOLISH() methods also get called; the
731 destructor will take care of that.
732 Each DEMOLISH() method is called with two arguments: the invocant
734 object, and the identifier number of that object. For example:
735 sub DEMOLISH {
737 my ($self, $ident) = @_;
738 $filehandle_of{$ident}->flush();
740 $filehandle_of{$ident}->close();
741 }
742 Note that the attributes of the object are cleaned up after the
744 DEMOLISH() method is complete, so they may still be used within
745 that method.
746 AUTOMETHOD()
748 There is a significant problem with Perl's built-in "AUTOLOAD"
749 mechanism: there's no way for a particular AUTOLOAD() to say "no".
750 If two or more classes in a class hierarchy have separate
752 AUTOLOAD() methods, then the one belonging to the left-most-depth-
753 first class in the inheritance tree will always be invoked in
754 preference to any others. If it can't handle a particular call,
755 the call will probably fail catastrophically. This means that
756 derived classes can't always be used in place of base classes (a
757 feature known as "Liskov substitutability") because their inherited
758 autoloading behaviour may be pre-empted by some other unrelated
759 base class on their left in the hierarchy.
760 Class::Std provides a mechanism that solves this problem: the
762 "AUTOMETHOD" method. An AUTOMETHOD() is expected to return either a
763 handler subroutine that implements the requested method
764 functionality, or else an "undef" to indicate that it doesn't know
765 how to handle the request. Class::Std then coordinates every
766 AUTOMETHOD() in an object's hierarchy, trying each one in turn
767 until one of them produces a suitable handler.
768 The advantage of this approach is that the first AUTOMETHOD()
770 that's invoked doesn't have to disenfranchise every other
771 AUTOMETHOD() in the hierarchy. If the first one can't handle a
772 particular method call, it simply declines it and Class::Std tries
773 the next candidate instead.
774 Using AUTOMETHOD() instead of AUTOLOAD() makes a class cleaner,
776 more robust, and less disruptive in class hierarchies. For
777 example:
778 package Phonebook;
780 use Class::Std;
781 {
782 my %entries_of : ATTR;
783 # Any method call is someone's name:
785 # so store their phone number or get it...
786 sub AUTOMETHOD {
787 my ($self, $ident, $number) = @_;
788 my $subname = $_; # Requested subroutine name is passed via $_
790 # Return failure if not a get_<name> or set_<name>
792 # (Next AUTOMETHOD() in hierarchy will then be tried instead)...
793 my ($mode, $name) = $subname =~ m/\A ([gs]et)_(.*) \z/xms
794 or return;
795 # If get_<name>, return a handler that just returns the old number...
797 return sub { return $entries_of{$ident}->{$name}; }
798 if $mode eq 'get';
799 # Otherwise, set_<name>, so return a handler that
801 # updates the entry and then returns the old number...
802 return sub {
803 $entries_of{$ident}->{$name} = $number;
804 return;
805 };
806 }
807 }
808 # and later...
810 my $lbb = Phonebook->new();
812 $lbb->set_Jenny(867_5309);
814 $lbb->set_Glenn(736_5000);
815 print $lbb->get_Jenny(), "\n";
817 print $lbb->get_Glenn(), "\n";
818 Note that, unlike AUTOLOAD(), an AUTOMETHOD() is called with both
820 the invocant and the invocant's unique "ident" number, followed by
821 the actual arguments that were passed to the method.
822 Note too that the name of the method being called is passed as $_
824 instead of $AUTOLOAD, and does not have the class name prepended to
825 it, so you don't have to strip that name off the front like almost
826 everyone almost always does in their AUTOLOAD(). If your
827 AUTOMETHOD() also needs to access the $_ from the caller's scope,
828 that's still available as $CALLER::_.
829 Variable traits that can be ascribed
831 The following markers can be added to the definition of any hash used
832 as an attribute storage within a Class::Std class
833 :ATTR()
835 This marker can be used to indicate that a lexical hash is being
836 used to store one particular attribute of all the objects of the
837 class. That is:
838 package File::Hierarchy;
840 {
841 my %root_of :ATTR;
842 my %files_of :ATTR;
843 # etc.
845 }
846 package File::Hierarchy::File;
848 {
849 my %name_of; :ATTR;
850 # etc.
852 }
853 Adding the ":ATTR" marker to an attribute hash ensures that the
855 corresponding attribute belonging to each object of the class is
856 automatically cleaned up when the object is destroyed.
857 The ":ATTR" marker can also be given a number of options which
859 automate other attribute-related behaviours. Each of these options
860 consists of a key/value pair, which may be specified in either Perl
861 5 "fat comma" syntax ( "key => 'value'" ) or in one of the Perl 6
862 option syntaxes ( ":key<value>" or :key('value') or ":key«value»").
863 Note that, due to a limitation in Perl itself, the complete ":ATTR"
865 marker, including its options must appear on a single line.
866 interpolate variables into the option values
867 :ATTR( :init_arg<initializer_key> )
869 This option tells Class::Std which key in the constructor's
870 initializer hash holds the value with which the marked
871 attribute should be initialized. That is, instead of writing:
872 my %rank_of :ATTR;
874 sub BUILD {
876 my ($self, $ident, $arg_ref) = @_;
877 $rank_of{$ident} = $arg_ref->{rank};
879 }
880 you can achieve the same initialization, by having Class::Std
882 automatically pull that entry out of the hash and store it in
883 the right attribute:
884 my %rank_of :ATTR( :init_arg<rank> );
886 # No BUILD() method required
888 :ATTR( :default<compile_time_default_value> )
890 If a marked attribute is not initialized (either directly
891 within a BUILD(), or automatically via an ":init_arg" option),
892 the constructor supplied by Class::Std checks to see if a
893 default value was specified for that attribute. If so, that
894 value is assigned to the attribute.
895 So you could replace:
897 my %seen_of :ATTR;
899 sub BUILD {
901 my ($self, $ident, $arg_ref) = @_;
902 $seen_of{$ident} = 0; # Not seen yet
904 }
905 with:
907 my %seen_of :ATTR( :default(0) );
909 # No BUILD() required
911 Note that only literal strings and numbers can be used as
913 default values. A common mistake is to write:
914 my %seen_of :ATTR( :default($some_variable) );
916 But variables like this aren't interpolated into ":ATTR"
918 markers (this is a limitation of Perl, not Class::Std).
919 If your attribute needs something more complex, you will have
921 to default initialize it in a START() method:
922 my %seen_of :ATTR;
924 sub START {
926 my ($self, $id, $args_ref) = @_;
927 if (!defined $seen_of{$id}) {
929 $seen_of{$id} = $some_variable;
930 }
931 }
932 :ATTR( :get<name> )
934 If the ":get" option is specified, a read accessor is created
935 for the corresponding attribute. The name of the accessor is
936 "get_" followed by whatever name is specified as the value of
937 the ":get" option. For example, instead of:
938 my %current_count_of :ATTR;
940 sub get_count {
942 my ($self) = @_;
943 return $current_count_of{ident($self)};
945 }
946 you can just write:
948 my %count_of :ATTR( :get<count> );
950 Note that there is no way to prevent Class::Std adding the
952 initial "get_" to each accessor name it creates. That's what
953 "standard" means. See Chapter 15 of Perl Best Practices
954 (O'Reilly, 2005) for a full discussion on why accessors should
955 be named this way.
956 :ATTR( :set<name> )
958 If the ":set" option is specified, a write accessor is created
959 for the corresponding attribute. The name of the accessor is
960 "set_" followed by whatever name is specified as the value of
961 the ":set" option. For example, instead of:
962 my %current_count_of :ATTR;
964 sub set_count {
966 my ($self, $new_value) = @_;
967 croak "Missing new value in call to 'set_count' method"
969 unless @_ == 2;
970 $current_count_of{ident($self)} = $new_value;
972 }
973 you can just write:
975 my %count_of :ATTR( :set<count> );
977 Note that there is no way to prevent Class::Std adding the
979 initial "set_" to each accessor name it creates. Nor is there
980 any way to create a combined "getter/setter" accessor. See
981 Chapter 15 of Perl Best Practices (O'Reilly, 2005) for a full
982 discussion on why accessors should be named and implemented
983 this way.
984 :ATTR( :name<name> )
986 Specifying the ":name" option is merely a convenient shorthand
987 for specifying all three of ":get", ":set", and ":init_arg".
988 You can, of course, specify two or more arguments in a single
990 :ATTR() specification:
991 my %rank_of : ATTR( :init_arg<starting_rank> :get<rank> :set<rank> );
993 :ATTRS()
995 This is just another name for the ":ATTR" marker (see above). The
996 plural form is convenient when you want to specify a series of
997 attribute hashes in the same statement:
998 my (
1000 %name_of,
1001 %rank_of,
1002 %snum_of,
1003 %age_of,
1004 %unit_of,
1005 %assignment_of,
1006 %medals_of,
1007 ) : ATTRS;
1008 Method traits that can be ascribed
1010 The following markers can be added to the definition of any subroutine
1011 used as a method within a Class::Std class
1012 :RESTRICTED()
1014 :PRIVATE()
1015 Occasionally, it is useful to be able to create subroutines that
1016 can only be accessed within a class's own hierarchy (that is, by
1017 derived classes). And sometimes it's even more useful to be able to
1018 create methods that can only be called within a class itself.
1019 Typically these types of methods are utility methods: subroutines
1021 that provide some internal service for a class, or a class
1022 hierarchy. Class::Std supports the creation of these kinds of
1023 methods by providing two special markers: :RESTRICTED() and
1024 :PRIVATE().
1025 Methods marked :RESTRICTED() are modified at the end of the
1027 compilation phase so that they throw an exception when called from
1028 outside a class's hierarchy. Methods marked :PRIVATE() are modified
1029 so that they throw an exception when called from outside the class
1030 in which they're declared.
1031 For example:
1033 package DogTag;
1035 use Class::Std;
1036 {
1037 my %ID_of : ATTR;
1038 my %rank_of : ATTR;
1039 my $ID_num = 0;
1041 sub _allocate_next_ID : RESTRICTED {
1043 my ($self) = @_;
1044 $ID_of{ident $self} = $ID_num++;
1045 return;
1046 }
1047 sub _check_rank : PRIVATE {
1049 my ($rank) = @_;
1050 return $rank if $VALID_RANK{$rank};
1051 croak "Unknown rank ($rank) specified";
1052 }
1053 sub BUILD {
1055 my ($self, $ident, $arg_ref) = @_;
1056 $self->_allocate_next_ID();
1058 $rank_of{$ident} = _check_rank($arg_ref->{rank});
1059 }
1060 }
1061 Of course, this code would run exactly the same without the
1063 :RESTRICTED() and :PRIVATE() markers, but they ensure that any
1064 attempt to call the two subroutines inappropriately:
1065 package main;
1067 my $dogtag = DogTag->new({ rank => 'PFC' });
1069 $dogtag->_allocate_next_ID();
1071 is suitably punished:
1073 Can't call restricted method DogTag::_allocate_next_ID() from class main
1075 :CUMULATIVE()
1077 One of the most important advantages of using the BUILD() and
1078 DEMOLISH() mechanisms supplied by Class::Std is that those methods
1079 don't require nested calls to their ancestral methods, via the
1080 "SUPER" pseudo-class. The constructor and destructor provided by
1081 Class::Std take care of the necessary redispatching automatically.
1082 Each BUILD() method can focus solely on its own responsibilities;
1083 it doesn't have to also help orchestrate the cumulative constructor
1084 effects across the class hierarchy by remembering to call
1085 "$self->SUPER::BUILD()".
1086 Moreover, calls via "SUPER" can only ever call the method of
1088 exactly one ancestral class, which is not sufficient under multiple
1089 inheritance.
1090 Class::Std provides a different way of creating methods whose
1092 effects accumulate through a class hierarchy, in the same way as
1093 those of BUILD() and DEMOLISH() do. Specifically, the module allows
1094 you to define your own "cumulative methods".
1095 An ordinary non-cumulative method hides any method of the same name
1097 inherited from any base class, so when a non-cumulative method is
1098 called, only the most-derived version of it is ever invoked. In
1099 contrast, a cumulative method doesn't hide ancestral methods of the
1100 same name; it assimilates them. When a cumulative method is called,
1101 the most-derived version of it is invoked, then any parental
1102 versions, then any grandparental versions, etc. etc, until every
1103 cumulative method of the same name throughout the entire hierarchy
1104 has been called.
1105 For example, you could define a cumulative describe() method to the
1107 various classes in a simple class hierarchy like so:
1108 package Wax::Floor;
1110 use Class::Std;
1111 {
1112 my %name_of :ATTR( init_arg => 'name' );
1113 my %patent_of :ATTR( init_arg => 'patent' );
1114 sub describe :CUMULATIVE {
1116 my ($self) = @_;
1117 print "The floor wax $name_of{ident $self} ",
1119 "(patent: $patent_of{ident $self})\n";
1120 return;
1122 }
1123 }
1124 package Topping::Dessert;
1126 use Class::Std;
1127 {
1128 my %name_of :ATTR( init_arg => 'name' );
1129 my %flavour_of :ATTR( init_arg => 'flavour' );
1130 sub describe :CUMULATIVE {
1132 my ($self) = @_;
1133 print "The dessert topping $name_of{ident $self} ",
1135 "with that great $flavour_of{ident $self} taste!\n";
1136 return;
1138 }
1139 }
1140 package Shimmer;
1142 use base qw( Wax::Floor Topping::Dessert );
1143 use Class::Std;
1144 {
1145 my %name_of :ATTR( init_arg => 'name' );
1146 my %patent_of :ATTR( init_arg => 'patent' );
1147 sub describe :CUMULATIVE {
1149 my ($self) = @_;
1150 print "New $name_of{ident $self} ",
1152 "(patent: $patent_of{ident $self})\n",
1153 "Combining...\n";
1154 return;
1156 }
1157 }
1158 Because the various describe() methods are marked as being
1160 cumulative, a subsequent call to:
1161 my $product
1163 = Shimmer->new({
1164 name => 'Shimmer',
1165 patent => 1562516251,
1166 flavour => 'Vanilla',
1167 });
1168 $product->describe();
1170 will work its way up through the classes of Shimmer's inheritance
1172 tree (in the same order as a destructor call would), calling each
1173 describe() method it finds along the way. So the single call to
1174 describe() would invoke the corresponding method in each class,
1175 producing:
1176 New Shimmer (patent: 1562516251)
1178 Combining...
1179 The floor wax Shimmer (patent: 1562516251)
1180 The dessert topping Shimmer with that great Vanilla taste!
1181 Note that the accumulation of describe() methods is hierarchical,
1183 and dynamic in nature. That is, each class only sees those
1184 cumulative methods that are defined in its own package or in one of
1185 its ancestors. So calling the same describe() on a base class
1186 object:
1187 my $wax
1189 = Wax::Floor->new({ name=>'Shimmer ', patent=>1562516251 });
1190 $wax->describe();
1192 only invokes the corresponding cumulative methods from that point
1194 on up the hierarchy, and hence only prints:
1195 The floor wax Shimmer (patent: 1562516251)
1197 Cumulative methods also accumulate their return values. In a list
1199 context, they return a (flattened) list that accumulates the lists
1200 returned by each individual method invoked.
1201 In a scalar context, a set of cumulative methods returns an object
1203 that, in a string context, concatenates individual scalar returns
1204 to produce a single string. When used as an array reference that
1205 same scalar-context-return object acts like an array of the list
1206 context values. When used as a hash reference, the object acts like
1207 a hash whose keys are the classnames from the object's hierarchy,
1208 and whose corresponding values are the return values of the
1209 cumulative method from that class.
1210 For example, if the classes each have a cumulative method that
1212 returns their list of sales features:
1213 package Wax::Floor;
1215 use Class::Std;
1216 {
1217 sub feature_list :CUMULATIVE {
1218 return ('Long-lasting', 'Non-toxic', 'Polymer-based');
1219 }
1220 }
1221 package Topping::Dessert;
1223 use Class::Std;
1224 {
1225 sub feature_list :CUMULATIVE {
1226 return ('Low-carb', 'Non-dairy', 'Sugar-free');
1227 }
1228 }
1229 package Shimmer;
1231 use Class::Std;
1232 use base qw( Wax::Floor Topping::Dessert );
1233 {
1234 sub feature_list :CUMULATIVE {
1235 return ('Multi-purpose', 'Time-saving', 'Easy-to-use');
1236 }
1237 }
1238 then calling feature_list() in a list context:
1240 my @features = Shimmer->feature_list();
1242 print "Shimmer is the @features alternative!\n";
1243 would produce a concatenated list of features, which could then be
1245 interpolated into a suitable sales-pitch:
1246 Shimmer is the Multi-purpose Time-saving Easy-to-use
1248 Long-lasting Non-toxic Polymer-based Low-carb Non-dairy
1249 Sugar-free alternative!
1250 It's also possible to specify a set of cumulative methods that
1252 start at the base class(es) of the hierarchy and work downwards,
1253 the way BUILD() does. To get that effect, you simply mark each
1254 method with :CUMULATIVE(BASE FIRST), instead of just :CUMULATIVE.
1255 For example:
1256 package Wax::Floor;
1258 use Class::Std;
1259 {
1260 sub active_ingredients :CUMULATIVE(BASE FIRST) {
1261 return "\tparadichlorobenzene, cyanoacrylate, peanuts\n";
1262 }
1263 }
1264 package Topping::Dessert;
1266 use Class::Std;
1267 {
1268 sub active_ingredients :CUMULATIVE(BASE FIRST) {
1269 return "\tsodium hypochlorite, isobutyl ketone, ethylene glycol\n";
1270 }
1271 }
1272 package Shimmer;
1274 use Class::Std;
1275 use base qw( Wax::Floor Topping::Dessert );
1276 {
1278 sub active_ingredients :CUMULATIVE(BASE FIRST) {
1279 return "\taromatic hydrocarbons, xylene, methyl mercaptan\n";
1280 }
1281 }
1282 So a scalar-context call to active_ingredients():
1284 my $ingredients = Shimmer->active_ingredients();
1286 print "May contain trace amounts of:\n$ingredients";
1287 would start in the base classes and work downwards, concatenating
1289 base- class ingredients before those of the derived class, to
1290 produce:
1291 May contain trace amounts of:
1293 paradichlorobenzene, cyanoacrylate, peanuts
1294 sodium hypochlorite, isobutyl ketone, ethylene glycol
1295 aromatic hydrocarbons, xylene, methyl mercaptan
1296 Or, you could treat the return value as a hash:
1298 print Data::Dumper::Dumper \%{$ingredients};
1300 and see which ingredients came from where:
1302 $VAR1 = {
1304 'Shimmer'
1305 => 'aromatic hydrocarbons, xylene, methyl mercaptan',
1306 'Topping::Dessert'
1308 => 'sodium hypochlorite, isobutyl ketone, ethylene glycol',
1309 'Wax::Floor'
1311 => 'Wax: paradichlorobenzene, hydrogen peroxide, cyanoacrylate',
1312 };
1313 Note that you can't specify both ":CUMULATIVE" and
1315 ":CUMULATIVE(BASE FIRST)" on methods of the same name in the same
1316 hierarchy. The resulting set of methods would have no well-defined
1317 invocation order, so Class::Std throws a compile-time exception
1318 instead.
1319 ":STRINGIFY"
1321 If you define a method and add the ":STRINGIFY" marker then that
1322 method is used whenever an object of the corresponding class needs
1323 to be coerced to a string. In other words, instead of:
1324 # Convert object to a string...
1326 sub as_str {
1327 ...
1328 }
1329 # Convert object to a string automatically in string contexts...
1331 use overload (
1332 q{""} => 'as_str',
1333 fallback => 1,
1334 );
1335 you can just write:
1337 # Convert object to a string (automatically in string contexts)...
1339 sub as_str : STRINGIFY {
1340 ...
1341 }
1342 ":NUMERIFY"
1344 If you define a method and add the ":NUMERIFY" marker then that
1345 method is used whenever an object of the corresponding class needs
1346 to be coerced to a number. In other words, instead of:
1347 # Convert object to a number...
1349 sub as_num {
1350 ...
1351 }
1352 # Convert object to a string automatically in string contexts...
1354 use overload (
1355 q{0+} => 'as_num',
1356 fallback => 1,
1357 );
1358 you can just write:
1360 # Convert object to a number (automatically in numeric contexts)...
1362 sub as_num : NUMERIFY {
1363 ...
1364 }
1365 ":BOOLIFY"
1367 If you define a method and add the ":BOOLIFY" marker then that
1368 method is used whenever an object of the corresponding class needs
1369 to be coerced to a boolean value. In other words, instead of:
1370 # Convert object to a boolean...
1372 sub as_bool {
1373 ...
1374 }
1375 # Convert object to a boolean automatically in boolean contexts...
1377 use overload (
1378 q{bool} => 'as_bool',
1379 fallback => 1,
1380 );
1381 you can just write:
1383 # Convert object to a boolean (automatically in boolean contexts)...
1385 sub as_bool : BOOLIFY {
1386 ...
1387 }
1388 ":SCALARIFY"
1390 ":ARRAYIFY"
1391 ":HASHIFY"
1392 ":GLOBIFY"
1393 ":CODIFY"
1394 If a method is defined with one of these markers, then it is
1395 automatically called whenever an object of that class is treated as
1396 a reference of the corresponding type.
1397 For example, instead of:
1399 sub as_hash {
1401 my ($self) = @_;
1402 return {
1404 age => $age_of{ident $self},
1405 shoesize => $shoe_of{ident $self},
1406 };
1407 }
1408 use overload (
1410 '%{}' => 'as_hash',
1411 fallback => 1,
1412 );
1413 you can just write:
1415 sub as_hash : HASHIFY {
1417 my ($self) = @_;
1418 return {
1420 age => $age_of{ident $self},
1421 shoesize => $shoe_of{ident $self},
1422 };
1423 }
1424 Likewise for methods that allow an object to be treated as a scalar
1426 reference (":SCALARIFY"), a array reference (":ARRAYIFY"), a
1427 subroutine reference (":CODIFY"), or a typeglob reference
1428 (":GLOBIFY").
1429
1431 Can't find class %s
1432 You tried to call the Class::Std::new() constructor on a class that
1433 isn't built using Class::Std. Did you forget to write "use
1434 Class::Std" after the package declaration?
1435 Argument to %s->new() must be hash reference
1437 The constructors created by Class::Std require all initializer
1438 values to be passed in a hash, but you passed something that wasn't
1439 a hash. Put your constructor arguments in a hash.
1440 Missing initializer label for %s: %s
1442 You specified that one or more attributes had initializer values
1443 (using the "init" argument inside the attribute's "ATTR" marker),
1444 but then failed to pass in the corresponding initialization value.
1445 Often this happens because the initialization value was passed, but
1446 the key specifying the attribute name was misspelled.
1447 Can't make anonymous subroutine cumulative
1449 You attempted to use the ":CUMULATIVE" marker on an anonymous
1450 subroutine. But that marker can only be applied to the named
1451 methods of a class. Convert the anonymous subroutine to a named
1452 subroutine, or find some other way to make it interoperate with
1453 other methods.
1454 Conflicting definitions for cumulative method: %s
1456 You defined a ":CUMULATIVE" and a ":CUMULATIVE(BASE FIRST)" method
1457 of the same name in two classes within the same hierarchy. Since
1458 methods can only be called going strictly up through the hierarchy
1459 or going strictly down through the hierarchy, specifying both
1460 directions is obviously a mistake. Either rename one of the
1461 methods, or decide whether they should accumulate upwards or
1462 downwards.
1463 Missing new value in call to 'set_%s' method
1465 You called an attribute setter method without providing a new value
1466 for the attribute. Often this happens because you passed an array
1467 that happened to be empty. Make sure you pass an actual value.
1468 Can't locate %s method "%s" via package %s
1470 You attempted to call a method on an object but no such method is
1471 defined anywhere in the object's class hierarchy. Did you misspell
1472 the method name, or perhaps misunderstand which class the object
1473 belongs to?
1474 %s method %s declared but not defined
1476 A method was declared with a ":RESTRICTED" or ":PRIVATE", like so:
1477 sub foo :RESTRICTED;
1479 sub bar :PRIVATE;
1480 But the actual subroutine was not defined by the end of the
1482 compilation phase, when the module needed it so it could be
1483 rewritten to restrict or privatize it.
1484 Can't call restricted method %s from class %s
1486 The specified method was declared with a ":RESTRICTED" marker but
1487 subsequently called from outside its class hierarchy. Did you call
1488 the wrong method, or the right method from the wrong place?
1489 Can't call private method %s from class %s
1491 The specified method was declared with a ":PRIVATE" marker but
1492 subsequently called from outside its own class. Did you call the
1493 wrong method, or the right method from the wrong place?
1494 Internal error: %s
1496 Your code is okay, but it uncovered a bug in the Class::Std module.
1497 "BUGS AND LIMITATIONS" explains how to report the problem.
1498
1500 Class::Std requires no configuration files or environment variables.
1501
1503 Class::Std depends on the following modules:
1504 • version
1506 • Scalar::Util
1508 • Data::Dumper
1510
1512 Incompatible with the Attribute::Handlers module, since both define
1513 meta-attributes named :ATTR.
1514
1516 • Does not handle threading (including fork() under Windows).
1517 • ":ATTR" declarations must all be on the same line (due to a
1519 limitation in Perl itself).
1520 • ":ATTR" declarations cannot include variables, since these are not
1522 interpolated into the declaration (a limitation in Perl itself).
1523 Please report any bugs or feature requests to
1525 "bug-class-std@rt.cpan.org", or through the web interface at
1526 <http://rt.cpan.org>.
1527
1529 Inside-out objects are gaining in popularity and there are now many
1530 other modules that implement frameworks for building inside-out
1531 classes. These include:
1532 Object::InsideOut
1534 Array-based objects, with support for threading. Many excellent
1535 features (especially thread-safety), but slightly less secure than
1536 Class::Std, due to non-encapsulation of attribute data addressing.
1537 Class::InsideOut
1539 A minimalist approach to building inside-out classes.
1540 Lexical::Attributes
1542 Uses source filters to provide a near-Perl 6 approach to declaring
1543 inside-out classes.
1544 Class::Std::Storable
1546 Adds serialization/deserialization to Class::Std.
1547
1549 Damian Conway "<DCONWAY@cpan.org>"
1550
1552 Copyright (c) 2005, Damian Conway "<DCONWAY@cpan.org>". All rights
1553 reserved.
1554 Portions of the documentation from "Perl Best Practices" copyright (c)
1556 2005 by O'Reilly Media, Inc. and reprinted with permission.
1557 This module is free software; you can redistribute it and/or modify it
1559 under the same terms as Perl itself.
1560
1562 BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
1563 FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT
1564 WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
1565 PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND,
1566 EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
1567 WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
1568 ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH
1569 YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
1570 NECESSARY SERVICING, REPAIR, OR CORRECTION.
1571 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
1573 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
1574 REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENCE, BE LIABLE
1575 TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL, OR
1576 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
1577 SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
1578 RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
1579 FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
1580 SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
1581 DAMAGES.
1582perl v5.36.0 2023-01-20 Class::Std(3)