4 Consistent formatting of this file is achieved with:
5 perl ./Porting/podtidy pod/perlobj.pod
10 perlobj - Perl object reference
14 This document provides a reference for Perl's object orientation
15 features. If you're looking for an introduction to object-oriented
16 programming in Perl, please see L<perlootut>.
18 In order to understand Perl objects, you first need to understand
19 references in Perl. See L<perlref> for details.
21 This document describes all of Perl's object-oriented (OO) features
22 from the ground up. If you're just looking to write some
23 object-oriented code of your own, you are probably better served by
24 using one of the object systems from CPAN described in L<perlootut>.
26 If you're looking to write your own object system, or you need to
27 maintain code which implements objects from scratch then this document
28 will help you understand exactly how Perl does object orientation.
30 There are a few basic principles which define object oriented Perl:
36 An object is simply a data structure that knows to which class it
41 A class is simply a package. A class provides methods that expect to
46 A method is simply a subroutine that expects a reference to an object
47 (or a package name, for class methods) as the first argument.
51 Let's look at each of these principles in depth.
53 =head2 An Object is Simply a Data Structure
54 X<object> X<bless> X<constructor> X<new>
56 Unlike many other languages which support object orientation, Perl does
57 not provide any special syntax for constructing an object. Objects are
58 merely Perl data structures (hashes, arrays, scalars, filehandles,
59 etc.) that have been explicitly associated with a particular class.
61 That explicit association is created by the built-in C<bless> function,
62 which is typically used within the I<constructor> subroutine of the
65 Here is a simple constructor:
72 return bless {}, $class;
75 The name C<new> isn't special. We could name our constructor something
83 return bless {}, $class;
86 The modern convention for OO modules is to always use C<new> as the
87 name for the constructor, but there is no requirement to do so. Any
88 subroutine that blesses a data structure into a class is a valid
91 In the previous examples, the C<{}> code creates a reference to an
92 empty anonymous hash. The C<bless> function then takes that reference
93 and associates the hash with the class in C<$class>. In the simplest
94 case, the C<$class> variable will end up containing the string "File".
96 We can also use a variable to store a reference to the data structure
97 that is being blessed as our object:
108 Once we've blessed the hash referred to by C<$self> we can start
109 calling methods on it. This is useful if you want to put object
110 initialization in its own separate method:
118 $self->_initialize();
123 Since the object is also a hash, you can treat it as one, using it to
124 store data associated with the object. Typically, code inside the class
125 can treat the hash as an accessible data structure, while code outside
126 the class should always treat the object as opaque. This is called
127 B<encapsulation>. Encapsulation means that the user of an object does
128 not have to know how it is implemented. The user simply calls
129 documented methods on the object.
131 Note, however, that (unlike most other OO languages) Perl does not
132 ensure or enforce encapsulation in any way. If you want objects to
133 actually I<be> opaque you need to arrange for that yourself. This can
134 be done in a varierty of ways, including using L<"Inside-Out objects">
135 or modules from CPAN.
137 =head3 Objects Are Blessed; Variables Are Not
139 When we bless something, we are not blessing the variable which
140 contains a reference to that thing, nor are we blessing the reference
141 that the variable stores; we are blessing the thing that the variable
142 refers to (sometimes known as the I<referent>). This is best
143 demonstrated with this code:
145 use Scalar::Util 'blessed';
151 print blessed( $bar ); # prints "Class"
153 $bar = "some other value";
154 print blessed( $bar ); # prints undef
156 When we call C<bless> on a variable, we are actually blessing the
157 underlying data structure that the variable refers to. We are not
158 blessing the reference itself, nor the variable that contains that
159 reference. That's why the second call to C<blessed( $bar )> returns
160 false. At that point C<$bar> is no longer storing a reference to an
163 You will sometimes see older books or documentation mention "blessing a
164 reference" or describe an object as a "blessed reference", but this is
165 incorrect. It isn't the reference that is blessed as an object; it's
166 the thing the reference refers to (i.e. the referent).
168 =head2 A Class is Simply a Package
169 X<class> X<package> X<@ISA> X<inheritance>
171 Perl does not provide any special syntax for class definitions. A
172 package is simply a namespace containing variables and subroutines. The
173 only difference is that in a class, the subroutines may expect a
174 reference to an object or the name of a class as the first argument.
175 This is purely a matter of convention, so a class may contain both
176 methods and subroutines which I<don't> operate on an object or class.
178 Each package contains a special array called C<@ISA>. The C<@ISA> array
179 contains a list of that class's parent classes, if any. This array is
180 examined when Perl does method resolution, which we will cover later.
182 It is possible to manually set C<@ISA>, and you may see this in older
183 Perl code. Much older code also uses the L<base> pragma. For new code,
184 we recommend that you use the L<parent> pragma to declare your parents.
185 This pragma will take care of setting C<@ISA>. It will also load the
186 parent classes and make sure that the package doesn't inherit from
189 However the parent classes are set, the package's C<@ISA> variable will
190 contain a list of those parents. This is simply a list of scalars, each
191 of which is a string that corresponds to a package name.
193 All classes inherit from the L<UNIVERSAL> class implicitly. The
194 L<UNIVERSAL> class is implemented by the Perl core, and provides
195 several default methods, such as C<isa()>, C<can()>, and C<VERSION()>.
196 The C<UNIVERSAL> class will I<never> appear in a package's C<@ISA>
199 Perl I<only> provides method inheritance as a built-in feature.
200 Attribute inheritance is left up the class to implement. See the
201 L</Writing Accessors> section for details.
203 =head2 A Method is Simply a Subroutine
206 Perl does not provide any special syntax for defining a method. A
207 method is simply a regular subroutine, and is declared with C<sub>.
208 What makes a method special is that it expects to receive either an
209 object or a class name as its first argument.
211 Perl I<does> provide special syntax for method invocation, the C<< ->
212 >> operator. We will cover this in more detail later.
214 Most methods you write will expect to operate on objects:
219 open my $fh, '>', $self->path() or die $!;
220 print {$fh} $self->data() or die $!;
224 =head2 Method Invocation
225 X<invocation> X<method> X<arrow> X<< -> >>
227 Calling a method on an object is written as C<< $object->method >>.
229 The left hand side of the method invocation (or arrow) operator is the
230 object (or class name), and the right hand side is the method name.
232 my $pod = File->new( 'perlobj.pod', $data );
235 The C<< -> >> syntax is also used when dereferencing a reference. It
236 looks like the same operator, but these are two different operations.
238 When you call a method, the thing on the left side of the arrow is
239 passed as the first argument to the method. That means when we call C<<
240 Critter->new() >>, the C<new()> method receives the string C<"Critter">
241 as its first argument. When we call C<< $fred->speak() >>, the C<$fred>
242 variable is passed as the first argument to C<speak()>.
244 Just as with any Perl subroutine, all of the arguments passed in C<@_>
245 are aliases to the original argument. This includes the object itself.
246 If you assign directly to C<$_[0]> you will change the contents of the
247 variable that holds the reference to the object. We recommend that you
248 don't do this unless you know exactly what you're doing.
250 Perl knows what package the method is in by looking at the left side of
251 the arrow. If the left hand side is a package name, it looks for the
252 method in that package. If the left hand side is an object, then Perl
253 looks for the method in the package that the object has been blessed
256 If the left hand side is neither a package name nor an object, then the
257 method call will cause an error, but see the section on L</Method Call
258 Variations> for more nuances.
263 We already talked about the special C<@ISA> array and the L<parent>
266 When a class inherits from another class, any methods defined in the
267 parent class are available to the child class. If you attempt to call a
268 method on an object that isn't defined in its own class, Perl will also
269 look for that method in any parent classes it may have.
272 use parent 'File'; # sets @File::MP3::ISA = ('File');
274 my $mp3 = File::MP3->new( 'Andvari.mp3', $data );
277 Since we didn't define a C<save()> method in the C<File::MP3> class,
278 Perl will look at the C<File::MP3> class's parent classes to find the
279 C<save()> method. If Perl cannot find a C<save()> method anywhere in
280 the inheritance hierarchy, it will die.
282 In this case, it finds a C<save()> method in the C<File> class. Note
283 that the object passed to C<save()> in this case is still a
284 C<File::MP3> object, even though the method is found in the C<File>
287 We can override a parent's method in a child class. When we do so, we
288 can still call the parent class's method with the C<SUPER>
294 say 'Prepare to rock';
295 $self->SUPER::save();
298 The C<SUPER> modifier can I<only> be used for method calls. You can't
299 use it for regular subroutine calls or class methods:
301 SUPER::save($thing); # FAIL: looks for save() sub in package SUPER
303 SUPER->save($thing); # FAIL: looks for save() method in class
306 $thing->SUPER::save(); # Okay: looks for save() method in parent
310 =head3 How SUPER is Resolved
313 The C<SUPER> pseudo-class is resolved from the package where the call
314 is made. It is I<not> resolved based on the object's class. This is
315 important, because it lets methods at different levels within a deep
316 inheritance hierarchy each correctly call their respective parent
322 return bless {}, shift;
328 $self->SUPER::speak();
340 $self->SUPER::speak();
352 $self->SUPER::speak();
360 In this example, we will get the following output:
366 This demonstrates how C<SUPER> is resolved. Even though the object is
367 blessed into the C<C> class, the C<speak()> method in the C<B> class
368 can still call C<SUPER::speak()> and expect it to correctly look in the
369 parent class of C<B> (i.e the class the method call is in), not in the
370 parent class of C<C> (i.e. the class the object belongs to).
372 There are rare cases where this package-based resolution can be a
373 problem. If you copy a subroutine from one package to another, C<SUPER>
374 resolution will be done based on the original package.
376 =head3 Multiple Inheritance
377 X<multiple inheritance>
379 Multiple inheritance often indicates a design problem, but Perl always
380 gives you enough rope to hang yourself with if you ask for it.
382 To declare multiple parents, you simply need to pass multiple class
383 names to C<use parent>:
387 use parent 'Parent1', 'Parent2';
389 =head3 Method Resolution Order
390 X<method resolution order> X<mro>
392 Method resolution order only matters in the case of multiple
393 inheritance. In the case of single inheritance, Perl simply looks up
394 the inheritance chain to find a method:
402 If we call a method on a C<Child> object and that method is not defined
403 in the C<Child> class, Perl will look for that method in the C<Parent>
404 class and then, if necessary, in the C<Grandparent> class.
406 If Perl cannot find the method in any of these classes, it will die
407 with an error message.
409 When a class has multiple parents, the method lookup order becomes more
412 By default, Perl does a depth-first left-to-right search for a method.
413 That means it starts with the first parent in the C<@ISA> array, and
414 then searches all of its parents, grandparents, etc. If it fails to
415 find the method, it then goes to the next parent in the original
416 class's C<@ISA> array and searches from there.
418 SharedGreatGrandParent
420 PaternalGrandparent MaternalGrandparent
426 So given the diagram above, Perl will search C<Child>, C<Father>,
427 C<PaternalGrandparent>, C<SharedGreatGrandParent>, C<Mother>, and
428 finally C<MaternalGrandparent>. This may be a problem because now we're
429 looking in C<SharedGreatGrandParent> I<before> we've checked all its
430 derived classes (i.e. before we tried C<Mother> and
431 C<MaternalGrandparent>).
433 It is possible to ask for a different method resolution order with the
439 use parent 'Father', 'Mother';
441 This pragma lets you switch to the "C3" resolution order. In simple
442 terms, "C3" order ensures that shared parent classes are never searched
443 before child classes, so Perl will now search: C<Child>, C<Father>,
444 C<PaternalGrandparent>, C<Mother> C<MaternalGrandparent>, and finally
445 C<SharedGreatGrandParent>. Note however that this is not
446 "breadth-first" searching: All the C<Father> ancestors (except the
447 common ancestor) are searched before any of the C<Mother> ancestors are
450 The C3 order also lets you call methods in sibling classes with the
451 C<next> pseudo-class. See the L<mro> documentation for more details on
454 =head3 Method Resolution Caching
456 When Perl searches for a method, it caches the lookup so that future
457 calls to the method do not need to search for it again. Changing a
458 class's parent class or adding subroutines to a class will invalidate
459 the cache for that class.
461 The L<mro> pragma provides some functions for manipulating the method
464 =head2 Writing Constructors
467 As we mentioned earlier, Perl provides no special constructor syntax.
468 This means that a class must implement its own constructor. A
469 constructor is simply a class method that returns a reference to a new
472 The constructor can also accept additional parameters that define the
473 object. Let's write a real constructor for the C<File> class we used
480 my ( $path, $data ) = @_;
490 As you can see, we've stored the path and file data in the object
491 itself. Remember, under the hood, this object is still just a hash.
492 Later, we'll write accessors to manipulate this data.
494 For our File::MP3 class, we can check to make sure that the path we're
495 given ends with ".mp3":
501 my ( $path, $data ) = @_;
503 die "You cannot create a File::MP3 without an mp3 extension\n"
504 unless $path =~ /\.mp3\z/;
506 return $class->SUPER::new(@_);
509 This constructor lets its parent class do the actual object
515 An attribute is a piece of data belonging to a particular object.
516 Unlike most object-oriented languages, Perl provides no special syntax
517 or support for declaring and manipulating attributes.
519 Attributes are often stored in the object itself. For example, if the
520 object is an anonymous hash, we can store the attribute values in the
521 hash using the attribute name as the key.
523 While it's possible to refer directly to these hash keys outside of the
524 class, it's considered a best practice to wrap all access to the
525 attribute with accessor methods.
527 This has several advantages. Accessors make it easier to change the
528 implementation of an object later while still preserving the original
531 An accessor lets you add additional code around attribute access. For
532 example, you could apply a default to an attribute that wasn't set in
533 the constructor, or you could validate that a new value for the
534 attribute is acceptable.
536 Finally, using accessors makes inheritance much simpler. Subclasses can
537 use the accessors rather than having to know how a parent class is
538 implemented internally.
540 =head3 Writing Accessors
543 As with constructors, Perl provides no special accessor declaration
544 syntax, so classes must provide explicitly written accessor methods.
545 There are two common types of accessors, read-only and read-write.
547 A simple read-only accessor simply gets the value of a single
553 return $self->{path};
556 A read-write accessor will allow the caller to set the value as well as
563 $self->{path} = shift;
566 return $self->{path};
569 =head2 An Aside About Smarter and Safer Code
571 Our constructor and accessors are not very smart. They don't check that
572 a C<$path> is defined, nor do they check that a C<$path> is a valid
575 Doing these checks by hand can quickly become tedious. Writing a bunch
576 of accessors by hand is also incredibly tedious. There are a lot of
577 modules on CPAN that can help you write safer and more concise code,
578 including the modules we recommend in L<perlootut>.
580 =head2 Method Call Variations
583 Perl supports several other ways to call methods besides the C<<
584 $object->method() >> usage we've seen so far.
586 =head3 Method Names as Strings
588 Perl lets you use a scalar variable containing a string as a method
591 my $file = File->new( $path, $data );
596 This works exactly like calling C<< $file->save() >>. This can be very
597 useful for writing dynamic code. For example, it allows you to pass a
598 method name to be called as a parameter to another method.
600 =head3 Class Names as Strings
602 Perl also lets you use a scalar containing a string as a class name:
606 my $file = $class->new( $path, $data );
608 Again, this allows for very dynamic code.
610 =head3 Subroutine References as Methods
612 You can also use a subroutine reference as a method:
622 This is exactly equivalent to writing C<< $sub->($file) >>. You may see
623 this idiom in the wild combined with a call to C<can>:
625 if ( my $meth = $object->can('foo') ) {
629 =head3 Deferencing Method Call
631 Perl also lets you use a dereferenced scalar reference in a method
632 call. That's a mouthful, so let's look at some code:
635 $file->${ returns_scalar_ref() };
636 $file->${ \( returns_scalar() ) };
637 $file->${ returns_sub_ref() };
639 This works if the dereference produces a string I<or> a subroutine
642 =head3 Method Calls on Filehandles
644 Under the hood, Perl filehandles are instances of the C<IO::Handle> or
645 C<IO::File> class. Once you have an open filehandle, you can call
646 methods on it. Additionally, you can call methods on the C<STDIN>,
647 C<STDOUT>, and C<STDERR> filehandles.
649 open my $fh, '>', 'path/to/file';
651 $fh->print('content');
655 =head2 Invoking Class Methods
658 Because Perl allows you to use barewords for package names and
659 subroutine names, it sometimes interprets a bareword's meaning
660 incorrectly. For example, the construct C<< Class->new() >> can be
661 interpreted as either C<< 'Class'->new() >> or C<< Class()->new() >>.
662 In English, that second interpretation reads as "call a subroutine
663 named Class(), then call new() as a method on the return value of
664 Class()". If there is a subroutine named C<Class()> in the current
665 namespace, Perl will always interpret C<< Class->new() >> as the second
666 alternative: a call to C<new()> on the object returned by a call to
669 You can force Perl to use the first interpretation (i.e. as a method
670 call on the class named "Class") in two ways. First, you can append a
671 C<::> to the class name:
675 Perl will always interpret this as a method call.
677 Alternatively, you can quote the class name:
681 Of course, if the class name is in a scalar Perl will do the right
687 =head3 Indirect Object Syntax
690 B<Outside of the file handle case, use of this syntax is discouraged,
691 as it can confuse the Perl interpreter. See below for more details.>
693 Perl suports another method invocation syntax called "indirect object"
694 notation. This syntax is called "indirect" because the method comes
695 before the object it is being invoked on.
697 This syntax can be used with any class or object method:
699 my $file = new File $path, $data;
702 We recommend that you avoid this syntax, for several reasons.
704 First, it can be confusing to read. In the above example, it's not
705 clear if C<save> is a method provided by the C<File> class or simply a
706 subroutine that expects a file object as its first argument.
708 When used with class methods, the problem is even worse. Because Perl
709 allows subroutine names to be written as barewords, Perl has to guess
710 whether the bareword after the method is a class name or subroutine
711 name. In other words, Perl can resolve the syntax as either C<<
712 File->new( $path, $data ) >> B<or> C<< new( File( $path, $data ) ) >>.
714 To parse this code, Perl uses a heuristic based on what package names
715 it has seen, what subroutines exist in the current package, what
716 barewords it has previously seen, and other input. Needless to say,
717 heuristics can produce very surprising results!
719 Older documentation (and some CPAN modules) encouraged this syntax,
720 particularly for constructors, so you may still find it in the wild.
721 However, we encourage you to avoid using it in new code.
723 You can force Perl to interpret the bareword as a class name by
724 appending "::" to it, like we saw earlier:
726 my $file = new File:: $path, $data;
728 =head2 C<bless>, C<blessed>, and C<ref>
730 As we saw earlier, an object is simply a data structure that has been
731 blessed into a class via the C<bless> function. The C<bless> function
732 can take either one or two arguments:
734 my $object = bless {}, $class;
735 my $object = bless {};
737 In the first form, the anonymous hash is being blessed into the class
738 in C<$class>. In the second form, the anonymous hash is blessed into
741 The second form is strongly discouraged, because it breaks the ability
742 of a subclass to reuse the parent's constructor, but you may still run
743 across it in existing code.
745 If you want to know whether a particular scalar refers to an object,
746 you can use the C<blessed> function exported by L<Scalar::Util>, which
747 is shipped with the Perl core.
749 use Scalar::Util 'blessed';
751 if ( defined blessed($thing) ) { ... }
753 If C<$thing> refers to an object, then this function returns the name
754 of the package the object has been blessed into. If C<$thing> doesn't
755 contain a reference to a blessed object, the C<blessed> function
758 Note that C<blessed($thing)> will also return false if C<$thing> has
759 been blessed into a class named "0". This is a possible, but quite
760 pathological. Don't create a class named "0" unless you know what
763 Similarly, Perl's built-in C<ref> function treats a reference to a
764 blessed object specially. If you call C<ref($thing)> and C<$thing>
765 holds a reference to an object, it will return the name of the class
766 that the object has been blessed into.
768 If you simply want to check that a variable contains an object
769 reference, we recommend that you use C<defined blessed($object)>, since
770 C<ref> returns true values for all references, not just objects.
772 =head2 The UNIVERSAL Class
775 All classes automatically inherit from the L<UNIVERSAL> class, which is
776 built-in to the Perl core. This class provides a number of methods, all
777 of which can be called on either a class or an object. You can also
778 choose to override some of these methods in your class. If you do so,
779 we recommend that you follow the built-in semantics described below.
786 The C<isa> method returns I<true> if the object is a member of the
787 class in C<$class>, or a member of a subclass of C<$class>.
789 If you override this method, it should never throw an exception.
794 The C<DOES> method returns I<true> if its object claims to perform the
795 role C<$role>. By default, this is equivalent to C<isa>. This method is
796 provided for use by object system extensions that implement roles, like
797 C<Moose> and C<Role::Tiny>.
799 You can also override C<DOES> directly in your own classes. If you
800 override this method, it should never throw an exception.
805 The C<can> method checks to see if the class or object it was called on
806 has a method named C<$method>. This checks for the method in the class
807 and all of its parents. If the method exists, then a reference to the
808 subroutine is returned. If it does not then C<undef> is returned.
810 If your class responds to method calls via C<AUTOLOAD>, you may want to
811 overload C<can> to return a subroutine reference for methods which your
812 C<AUTOLOAD> method handles.
814 If you override this method, it should never throw an exception.
819 The C<VERSION> method returns the version number of the class
822 If the C<$need> argument is given then it will check that the current
823 version (as defined by the $VERSION variable in the package) is greater
824 than or equal to C<$need>; it will die if this is not the case. This
825 method is called automatically by the C<VERSION> form of C<use>.
827 use Package 1.2 qw(some imported subs);
829 Package->VERSION(1.2);
831 We recommend that you use this method to access another package's
832 version, rather than looking directly at C<$Package::VERSION>. The
833 package you are looking at could have overridden the C<VERSION> method.
835 We also recommend using this method to check whether a module has a
836 sufficient version. The internal implementation uses the L<version>
837 module to make sure that different types of version numbers are
845 If you call a method that doesn't exist in a class, Perl will throw an
846 error. However, if that class or any of its parent classes defines an
847 C<AUTOLOAD> method, that C<AUTOLOAD> method is called instead.
849 C<AUTOLOAD> is called as a regular method, and the caller will not know
850 the difference. Whatever value your C<AUTOLOAD> method returns is
851 returned to the caller.
853 The fully qualified method name that was called is available in the
854 C<$AUTOLOAD> package global for your class. Since this is a global, if
855 you want to refer to do it without a package name prefix under C<strict
856 'vars'>, you need to declare it.
858 # XXX - this is a terrible way to implement accessors, but it makes
859 # for a simple example.
864 # Remove qualifier from original method name...
865 my $called = $AUTOLOAD =~ s/.*:://r;
867 # Is there an attribute of that name?
868 die "No such attribute: $called"
869 unless exists $self->{$called};
871 # If so, return it...
872 return $self->{$called};
875 sub DESTROY { } # see below
877 Without the C<our $AUTOLOAD> declaration, this code will not compile
878 under the L<strict> pragma.
880 As the comment says, this is not a good way to implement accessors.
881 It's slow and too clever by far. However, you may see this as a way to
882 provide accessors in older Perl code. See L<perlootut> for
883 recommendations on OO coding in Perl.
885 If your class does have an C<AUTOLOAD> method, we strongly recommend
886 that you override C<can> in your class as well. Your overridden C<can>
887 method should return a subroutine reference for any method that your
888 C<AUTOLOAD> responds to.
891 X<destructor> X<DESTROY>
893 When the last reference to an object goes away, the object is
894 destroyed. If you only have one reference to an object stored in a
895 lexical scalar, the object is destroyed when that scalar goes out of
896 scope. If you store the object in a package global, that object may not
897 go out of scope until the program exits.
899 If you want to do something when the object is destroyed, you can
900 define a C<DESTROY> method in your class. This method will always be
901 called by Perl at the appropriate time, unless the method is empty.
903 This is called just like any other method, with the object as the first
904 argument. It does not receive any additional arguments. However, the
905 C<$_[0]> variable will be read-only in the destructor, so you cannot
906 assign a value to it.
908 If your C<DESTROY> method throws an error, this error will be ignored.
909 It will not be sent to C<STDERR> and it will not cause the program to
910 die. However, if your destructor is running inside an C<eval {}> block,
911 then the error will change the value of C<$@>.
913 Because C<DESTROY> methods can be called at any time, you should
914 localize any global variables you might update in your C<DESTROY>. In
915 particular, if you use C<eval {}> you should localize C<$@>, and if you
916 use C<system> or backticks, you should localize C<$?>.
918 If you define an C<AUTOLOAD> in your class, then Perl will call your
919 C<AUTOLOAD> to handle the C<DESTROY> method. You can prevent this by
920 defining an empty C<DESTROY>, like we did in the autoloading example.
921 You can also check the value of C<$AUTOLOAD> and return without doing
922 anything when called to handle C<DESTROY>.
924 =head3 Global Destruction
926 The order in which objects are destroyed during the global destruction
927 before the program exits is unpredictable. This means that any objects
928 contained by your object may already have been destroyed. You should
929 check that a contained object is defined before calling a method on it:
934 $self->{handle}->close() if $self->{handle};
937 You can use the C<${^GLOBAL_PHASE}> variable to detect if you are
938 currently in the global destruction phase:
943 return if ${^GLOBAL_PHASE} eq 'DESTRUCT';
945 $self->{handle}->close();
948 Note that this variable was added in Perl 5.14.0. If you want to detect
949 the global destruction phase on older versions of Perl, you can use the
950 C<Devel::GlobalDestruction> module on CPAN.
952 If your C<DESTROY> method issues a warning during global destruction,
953 the Perl interpreter will append the string " during global
954 destruction" the warning.
956 During global destruction, Perl will always garbage collect objects
957 before unblessed references. See L<perlhacktips/PERL_DESTRUCT_LEVEL>
958 for more information about global destruction.
960 =head2 Non-Hash Objects
962 All the examples so far have shown objects based on a blessed hash.
963 However, it's possible to bless any type of data structure or referent,
964 including scalars, globs, and subroutines. You may see this sort of
965 thing when looking at code in the wild.
967 Here's an example of a module as a blessed scalar:
978 return bless \$time, $class;
986 my $time = Time->new();
987 print $time->epoch();
989 =head2 Inside-Out objects
991 In the past, the Perl community experimented with a technique called
992 "inside-out objects". An inside-out object stores its data outside of
993 the object's reference, indexed on a unique property of the object,
994 such as its memory address, rather than in the object itself. This has
995 the advantage of enforcing the encapsulation of object attributes,
996 since their data is not stored in the object itself.
998 This technique was popular for a while (and was recommended in Damian
999 Conway's I<Perl Best Practices>), but never achieved universal
1000 adoption. The L<Object::InsideOut> module on CPAN provides a
1001 comprehensive implementation of this technique, and you may see it or
1002 other inside-out modules in the wild.
1004 Here is a simple example of the technique, using the
1005 L<Hash::Util::FieldHash> core module. This module was added to the core
1006 to support inside-out object implementations.
1013 use Hash::Util::FieldHash 'fieldhash';
1015 fieldhash my %time_for;
1020 my $self = bless \( my $object ), $class;
1022 $time_for{$self} = time;
1030 return $time_for{$self};
1033 my $time = Time->new;
1036 =head2 Pseudo-hashes
1038 The pseudo-hash feature was an experimental feature introduced in
1039 earlier versions of Perl and removed in 5.10.0. A pseudo-hash is an
1040 array reference which can be accessed using named keys like a hash. You
1041 may run in to some code in the wild which uses it. See the L<fields>
1042 pragma for more information.
1046 A kinder, gentler tutorial on object-oriented programming in Perl can
1047 be found in L<perlootut>. You should also check out L<perlmodlib> for
1048 some style guides on constructing both modules and classes.