1PERLTOOC(1) Perl Programmers Reference Guide PERLTOOC(1)
2
6 perltooc - Tom's OO Tutorial for Class Data in Perl
7
9 When designing an object class, you are sometimes faced with the situa‐
10 tion of wanting common state shared by all objects of that class. Such
11 class attributes act somewhat like global variables for the entire
12 class, but unlike program-wide globals, class attributes have meaning
13 only to the class itself.
14 Here are a few examples where class attributes might come in handy:
16 · to keep a count of the objects you've created, or how many are
18 still extant.
19 · to extract the name or file descriptor for a logfile used by a
21 debugging method.
22 · to access collective data, like the total amount of cash dispensed
24 by all ATMs in a network in a given day.
25 · to access the last object created by a class, or the most accessed
27 object, or to retrieve a list of all objects.
28 Unlike a true global, class attributes should not be accessed directly.
30 Instead, their state should be inspected, and perhaps altered, only
31 through the mediated access of class methods. These class attributes
32 accessor methods are similar in spirit and function to accessors used
33 to manipulate the state of instance attributes on an object. They pro‐
34 vide a clear firewall between interface and implementation.
35 You should allow access to class attributes through either the class
37 name or any object of that class. If we assume that $an_object is of
38 type Some_Class, and the &Some_Class::population_count method accesses
39 class attributes, then these two invocations should both be possible,
40 and almost certainly equivalent.
41 Some_Class->population_count()
43 $an_object->population_count()
44 The question is, where do you store the state which that method
46 accesses? Unlike more restrictive languages like C++, where these are
47 called static data members, Perl provides no syntactic mechanism to
48 declare class attributes, any more than it provides a syntactic mecha‐
49 nism to declare instance attributes. Perl provides the developer with
50 a broad set of powerful but flexible features that can be uniquely
51 crafted to the particular demands of the situation.
52 A class in Perl is typically implemented in a module. A module con‐
54 sists of two complementary feature sets: a package for interfacing with
55 the outside world, and a lexical file scope for privacy. Either of
56 these two mechanisms can be used to implement class attributes. That
57 means you get to decide whether to put your class attributes in package
58 variables or to put them in lexical variables.
59 And those aren't the only decisions to make. If you choose to use
61 package variables, you can make your class attribute accessor methods
62 either ignorant of inheritance or sensitive to it. If you choose lexi‐
63 cal variables, you can elect to permit access to them from anywhere in
64 the entire file scope, or you can limit direct data access exclusively
65 to the methods implementing those attributes.
66
68 One of the easiest ways to solve a hard problem is to let someone else
69 do it for you! In this case, Class::Data::Inheritable (available on a
70 CPAN near you) offers a canned solution to the class data problem using
71 closures. So before you wade into this document, consider having a
72 look at that module.
73
75 Because a class in Perl is really just a package, using package vari‐
76 ables to hold class attributes is the most natural choice. This makes
77 it simple for each class to have its own class attributes. Let's say
78 you have a class called Some_Class that needs a couple of different
79 attributes that you'd like to be global to the entire class. The sim‐
80 plest thing to do is to use package variables like $Some_Class::CData1
81 and $Some_Class::CData2 to hold these attributes. But we certainly
82 don't want to encourage outsiders to touch those data directly, so we
83 provide methods to mediate access.
84 In the accessor methods below, we'll for now just ignore the first
86 argument--that part to the left of the arrow on method invocation,
87 which is either a class name or an object reference.
88 package Some_Class;
90 sub CData1 {
91 shift; # XXX: ignore calling class/object
92 $Some_Class::CData1 = shift if @_;
93 return $Some_Class::CData1;
94 }
95 sub CData2 {
96 shift; # XXX: ignore calling class/object
97 $Some_Class::CData2 = shift if @_;
98 return $Some_Class::CData2;
99 }
100 This technique is highly legible and should be completely straightfor‐
102 ward to even the novice Perl programmer. By fully qualifying the pack‐
103 age variables, they stand out clearly when reading the code. Unfortu‐
104 nately, if you misspell one of these, you've introduced an error that's
105 hard to catch. It's also somewhat disconcerting to see the class name
106 itself hard-coded in so many places.
107 Both these problems can be easily fixed. Just add the "use strict"
109 pragma, then pre-declare your package variables. (The "our" operator
110 will be new in 5.6, and will work for package globals just like "my"
111 works for scoped lexicals.)
112 package Some_Class;
114 use strict;
115 our($CData1, $CData2); # our() is new to perl5.6
116 sub CData1 {
117 shift; # XXX: ignore calling class/object
118 $CData1 = shift if @_;
119 return $CData1;
120 }
121 sub CData2 {
122 shift; # XXX: ignore calling class/object
123 $CData2 = shift if @_;
124 return $CData2;
125 }
126 As with any other global variable, some programmers prefer to start
128 their package variables with capital letters. This helps clarity some‐
129 what, but by no longer fully qualifying the package variables, their
130 significance can be lost when reading the code. You can fix this eas‐
131 ily enough by choosing better names than were used here.
132 Putting All Your Eggs in One Basket
134 Just as the mindless enumeration of accessor methods for instance
136 attributes grows tedious after the first few (see perltoot), so too
137 does the repetition begin to grate when listing out accessor methods
138 for class data. Repetition runs counter to the primary virtue of a
139 programmer: Laziness, here manifesting as that innate urge every pro‐
140 grammer feels to factor out duplicate code whenever possible.
141 Here's what to do. First, make just one hash to hold all class
143 attributes.
144 package Some_Class;
146 use strict;
147 our %ClassData = ( # our() is new to perl5.6
148 CData1 => "",
149 CData2 => "",
150 );
151 Using closures (see perlref) and direct access to the package symbol
153 table (see perlmod), now clone an accessor method for each key in the
154 %ClassData hash. Each of these methods is used to fetch or store val‐
155 ues to the specific, named class attribute.
156 for my $datum (keys %ClassData) {
158 no strict "refs"; # to register new methods in package
159 *$datum = sub {
160 shift; # XXX: ignore calling class/object
161 $ClassData{$datum} = shift if @_;
162 return $ClassData{$datum};
163 }
164 }
165 It's true that you could work out a solution employing an &AUTOLOAD
167 method, but this approach is unlikely to prove satisfactory. Your
168 function would have to distinguish between class attributes and object
169 attributes; it could interfere with inheritance; and it would have to
170 careful about DESTROY. Such complexity is uncalled for in most cases,
171 and certainly in this one.
172 You may wonder why we're rescinding strict refs for the loop. We're
174 manipulating the package's symbol table to introduce new function names
175 using symbolic references (indirect naming), which the strict pragma
176 would otherwise forbid. Normally, symbolic references are a dodgy
177 notion at best. This isn't just because they can be used accidentally
178 when you aren't meaning to. It's also because for most uses to which
179 beginning Perl programmers attempt to put symbolic references, we have
180 much better approaches, like nested hashes or hashes of arrays. But
181 there's nothing wrong with using symbolic references to manipulate
182 something that is meaningful only from the perspective of the package
183 symbol table, like method names or package variables. In other words,
184 when you want to refer to the symbol table, use symbol references.
185 Clustering all the class attributes in one place has several advan‐
187 tages. They're easy to spot, initialize, and change. The aggregation
188 also makes them convenient to access externally, such as from a debug‐
189 ger or a persistence package. The only possible problem is that we
190 don't automatically know the name of each class's class object, should
191 it have one. This issue is addressed below in "The Eponymous
192 Meta-Object".
193 Inheritance Concerns
195 Suppose you have an instance of a derived class, and you access class
197 data using an inherited method call. Should that end up referring to
198 the base class's attributes, or to those in the derived class? How
199 would it work in the earlier examples? The derived class inherits all
200 the base class's methods, including those that access class attributes.
201 But what package are the class attributes stored in?
202 The answer is that, as written, class attributes are stored in the
204 package into which those methods were compiled. When you invoke the
205 &CData1 method on the name of the derived class or on one of that
206 class's objects, the version shown above is still run, so you'll access
207 $Some_Class::CData1--or in the method cloning version,
208 $Some_Class::ClassData{CData1}.
209 Think of these class methods as executing in the context of their base
211 class, not in that of their derived class. Sometimes this is exactly
212 what you want. If Feline subclasses Carnivore, then the population of
213 Carnivores in the world should go up when a new Feline is born. But
214 what if you wanted to figure out how many Felines you have apart from
215 Carnivores? The current approach doesn't support that.
216 You'll have to decide on a case-by-case basis whether it makes any
218 sense for class attributes to be package-relative. If you want it to
219 be so, then stop ignoring the first argument to the function. Either
220 it will be a package name if the method was invoked directly on a class
221 name, or else it will be an object reference if the method was invoked
222 on an object reference. In the latter case, the ref() function pro‐
223 vides the class of that object.
224 package Some_Class;
226 sub CData1 {
227 my $obclass = shift;
228 my $class = ref($obclass) ⎪⎪ $obclass;
229 my $varname = $class . "::CData1";
230 no strict "refs"; # to access package data symbolically
231 $$varname = shift if @_;
232 return $$varname;
233 }
234 And then do likewise for all other class attributes (such as CData2,
236 etc.) that you wish to access as package variables in the invoking
237 package instead of the compiling package as we had previously.
238 Once again we temporarily disable the strict references ban, because
240 otherwise we couldn't use the fully-qualified symbolic name for the
241 package global. This is perfectly reasonable: since all package vari‐
242 ables by definition live in a package, there's nothing wrong with
243 accessing them via that package's symbol table. That's what it's there
244 for (well, somewhat).
245 What about just using a single hash for everything and then cloning
247 methods? What would that look like? The only difference would be the
248 closure used to produce new method entries for the class's symbol ta‐
249 ble.
250 no strict "refs";
252 *$datum = sub {
253 my $obclass = shift;
254 my $class = ref($obclass) ⎪⎪ $obclass;
255 my $varname = $class . "::ClassData";
256 $varname->{$datum} = shift if @_;
257 return $varname->{$datum};
258 }
259 The Eponymous Meta-Object
261 It could be argued that the %ClassData hash in the previous example is
263 neither the most imaginative nor the most intuitive of names. Is there
264 something else that might make more sense, be more useful, or both?
265 As it happens, yes, there is. For the "class meta-object", we'll use a
267 package variable of the same name as the package itself. Within the
268 scope of a package Some_Class declaration, we'll use the eponymously
269 named hash %Some_Class as that class's meta-object. (Using an epony‐
270 mously named hash is somewhat reminiscent of classes that name their
271 constructors eponymously in the Python or C++ fashion. That is, class
272 Some_Class would use &Some_Class::Some_Class as a constructor, probably
273 even exporting that name as well. The StrNum class in Recipe 13.14 in
274 The Perl Cookbook does this, if you're looking for an example.)
275 This predictable approach has many benefits, including having a well-
277 known identifier to aid in debugging, transparent persistence, or
278 checkpointing. It's also the obvious name for monadic classes and
279 translucent attributes, discussed later.
280 Here's an example of such a class. Notice how the name of the hash
282 storing the meta-object is the same as the name of the package used to
283 implement the class.
284 package Some_Class;
286 use strict;
287 # create class meta-object using that most perfect of names
289 our %Some_Class = ( # our() is new to perl5.6
290 CData1 => "",
291 CData2 => "",
292 );
293 # this accessor is calling-package-relative
295 sub CData1 {
296 my $obclass = shift;
297 my $class = ref($obclass) ⎪⎪ $obclass;
298 no strict "refs"; # to access eponymous meta-object
299 $class->{CData1} = shift if @_;
300 return $class->{CData1};
301 }
302 # but this accessor is not
304 sub CData2 {
305 shift; # XXX: ignore calling class/object
306 no strict "refs"; # to access eponymous meta-object
307 __PACKAGE__ -> {CData2} = shift if @_;
308 return __PACKAGE__ -> {CData2};
309 }
310 In the second accessor method, the __PACKAGE__ notation was used for
312 two reasons. First, to avoid hardcoding the literal package name in
313 the code in case we later want to change that name. Second, to clarify
314 to the reader that what matters here is the package currently being
315 compiled into, not the package of the invoking object or class. If the
316 long sequence of non-alphabetic characters bothers you, you can always
317 put the __PACKAGE__ in a variable first.
318 sub CData2 {
320 shift; # XXX: ignore calling class/object
321 no strict "refs"; # to access eponymous meta-object
322 my $class = __PACKAGE__;
323 $class->{CData2} = shift if @_;
324 return $class->{CData2};
325 }
326 Even though we're using symbolic references for good not evil, some
328 folks tend to become unnerved when they see so many places with strict
329 ref checking disabled. Given a symbolic reference, you can always pro‐
330 duce a real reference (the reverse is not true, though). So we'll cre‐
331 ate a subroutine that does this conversion for us. If invoked as a
332 function of no arguments, it returns a reference to the compiling
333 class's eponymous hash. Invoked as a class method, it returns a refer‐
334 ence to the eponymous hash of its caller. And when invoked as an
335 object method, this function returns a reference to the eponymous hash
336 for whatever class the object belongs to.
337 package Some_Class;
339 use strict;
340 our %Some_Class = ( # our() is new to perl5.6
342 CData1 => "",
343 CData2 => "",
344 );
345 # tri-natured: function, class method, or object method
347 sub _classobj {
348 my $obclass = shift ⎪⎪ __PACKAGE__;
349 my $class = ref($obclass) ⎪⎪ $obclass;
350 no strict "refs"; # to convert sym ref to real one
351 return \%$class;
352 }
353 for my $datum (keys %{ _classobj() } ) {
355 # turn off strict refs so that we can
356 # register a method in the symbol table
357 no strict "refs";
358 *$datum = sub {
359 use strict "refs";
360 my $self = shift->_classobj();
361 $self->{$datum} = shift if @_;
362 return $self->{$datum};
363 }
364 }
365 Indirect References to Class Data
367 A reasonably common strategy for handling class attributes is to store
369 a reference to each package variable on the object itself. This is a
370 strategy you've probably seen before, such as in perltoot and perlbot,
371 but there may be variations in the example below that you haven't
372 thought of before.
373 package Some_Class;
375 our($CData1, $CData2); # our() is new to perl5.6
376 sub new {
378 my $obclass = shift;
379 return bless my $self = {
380 ObData1 => "",
381 ObData2 => "",
382 CData1 => \$CData1,
383 CData2 => \$CData2,
384 } => (ref $obclass ⎪⎪ $obclass);
385 }
386 sub ObData1 {
388 my $self = shift;
389 $self->{ObData1} = shift if @_;
390 return $self->{ObData1};
391 }
392 sub ObData2 {
394 my $self = shift;
395 $self->{ObData2} = shift if @_;
396 return $self->{ObData2};
397 }
398 sub CData1 {
400 my $self = shift;
401 my $dataref = ref $self
402 ? $self->{CData1}
403 : \$CData1;
404 $$dataref = shift if @_;
405 return $$dataref;
406 }
407 sub CData2 {
409 my $self = shift;
410 my $dataref = ref $self
411 ? $self->{CData2}
412 : \$CData2;
413 $$dataref = shift if @_;
414 return $$dataref;
415 }
416 As written above, a derived class will inherit these methods, which
418 will consequently access package variables in the base class's package.
419 This is not necessarily expected behavior in all circumstances. Here's
420 an example that uses a variable meta-object, taking care to access the
421 proper package's data.
422 package Some_Class;
424 use strict;
425 our %Some_Class = ( # our() is new to perl5.6
427 CData1 => "",
428 CData2 => "",
429 );
430 sub _classobj {
432 my $self = shift;
433 my $class = ref($self) ⎪⎪ $self;
434 no strict "refs";
435 # get (hard) ref to eponymous meta-object
436 return \%$class;
437 }
438 sub new {
440 my $obclass = shift;
441 my $classobj = $obclass->_classobj();
442 bless my $self = {
443 ObData1 => "",
444 ObData2 => "",
445 CData1 => \$classobj->{CData1},
446 CData2 => \$classobj->{CData2},
447 } => (ref $obclass ⎪⎪ $obclass);
448 return $self;
449 }
450 sub ObData1 {
452 my $self = shift;
453 $self->{ObData1} = shift if @_;
454 return $self->{ObData1};
455 }
456 sub ObData2 {
458 my $self = shift;
459 $self->{ObData2} = shift if @_;
460 return $self->{ObData2};
461 }
462 sub CData1 {
464 my $self = shift;
465 $self = $self->_classobj() unless ref $self;
466 my $dataref = $self->{CData1};
467 $$dataref = shift if @_;
468 return $$dataref;
469 }
470 sub CData2 {
472 my $self = shift;
473 $self = $self->_classobj() unless ref $self;
474 my $dataref = $self->{CData2};
475 $$dataref = shift if @_;
476 return $$dataref;
477 }
478 Not only are we now strict refs clean, using an eponymous meta-object
480 seems to make the code cleaner. Unlike the previous version, this one
481 does something interesting in the face of inheritance: it accesses the
482 class meta-object in the invoking class instead of the one into which
483 the method was initially compiled.
484 You can easily access data in the class meta-object, making it easy to
486 dump the complete class state using an external mechanism such as when
487 debugging or implementing a persistent class. This works because the
488 class meta-object is a package variable, has a well-known name, and
489 clusters all its data together. (Transparent persistence is not always
490 feasible, but it's certainly an appealing idea.)
491 There's still no check that object accessor methods have not been
493 invoked on a class name. If strict ref checking is enabled, you'd blow
494 up. If not, then you get the eponymous meta-object. What you do
495 with--or about--this is up to you. The next two sections demonstrate
496 innovative uses for this powerful feature.
497 Monadic Classes
499 Some of the standard modules shipped with Perl provide class interfaces
501 without any attribute methods whatsoever. The most commonly used mod‐
502 ule not numbered amongst the pragmata, the Exporter module, is a class
503 with neither constructors nor attributes. Its job is simply to provide
504 a standard interface for modules wishing to export part of their names‐
505 pace into that of their caller. Modules use the Exporter's &import
506 method by setting their inheritance list in their package's @ISA array
507 to mention "Exporter". But class Exporter provides no constructor, so
508 you can't have several instances of the class. In fact, you can't have
509 any--it just doesn't make any sense. All you get is its methods. Its
510 interface contains no statefulness, so state data is wholly superflu‐
511 ous.
512 Another sort of class that pops up from time to time is one that sup‐
514 ports a unique instance. Such classes are called monadic classes, or
515 less formally, singletons or highlander classes.
516 If a class is monadic, where do you store its state, that is, its
518 attributes? How do you make sure that there's never more than one
519 instance? While you could merely use a slew of package variables, it's
520 a lot cleaner to use the eponymously named hash. Here's a complete
521 example of a monadic class:
522 package Cosmos;
524 %Cosmos = ();
525 # accessor method for "name" attribute
527 sub name {
528 my $self = shift;
529 $self->{name} = shift if @_;
530 return $self->{name};
531 }
532 # read-only accessor method for "birthday" attribute
534 sub birthday {
535 my $self = shift;
536 die "can't reset birthday" if @_; # XXX: croak() is better
537 return $self->{birthday};
538 }
539 # accessor method for "stars" attribute
541 sub stars {
542 my $self = shift;
543 $self->{stars} = shift if @_;
544 return $self->{stars};
545 }
546 # oh my - one of our stars just went out!
548 sub supernova {
549 my $self = shift;
550 my $count = $self->stars();
551 $self->stars($count - 1) if $count > 0;
552 }
553 # constructor/initializer method - fix by reboot
555 sub bigbang {
556 my $self = shift;
557 %$self = (
558 name => "the world according to tchrist",
559 birthday => time(),
560 stars => 0,
561 );
562 return $self; # yes, it's probably a class. SURPRISE!
563 }
564 # After the class is compiled, but before any use or require
566 # returns, we start off the universe with a bang.
567 __PACKAGE__ -> bigbang();
568 Hold on, that doesn't look like anything special. Those attribute
570 accessors look no different than they would if this were a regular
571 class instead of a monadic one. The crux of the matter is there's
572 nothing that says that $self must hold a reference to a blessed object.
573 It merely has to be something you can invoke methods on. Here the
574 package name itself, Cosmos, works as an object. Look at the &super‐
575 nova method. Is that a class method or an object method? The answer
576 is that static analysis cannot reveal the answer. Perl doesn't care,
577 and neither should you. In the three attribute methods, %$self is
578 really accessing the %Cosmos package variable.
579 If like Stephen Hawking, you posit the existence of multiple, sequen‐
581 tial, and unrelated universes, then you can invoke the &bigbang method
582 yourself at any time to start everything all over again. You might
583 think of &bigbang as more of an initializer than a constructor, since
584 the function doesn't allocate new memory; it only initializes what's
585 already there. But like any other constructor, it does return a scalar
586 value to use for later method invocations.
587 Imagine that some day in the future, you decide that one universe just
589 isn't enough. You could write a new class from scratch, but you
590 already have an existing class that does what you want--except that
591 it's monadic, and you want more than just one cosmos.
592 That's what code reuse via subclassing is all about. Look how short
594 the new code is:
595 package Multiverse;
597 use Cosmos;
598 @ISA = qw(Cosmos);
599 sub new {
601 my $protoverse = shift;
602 my $class = ref($protoverse) ⎪⎪ $protoverse;
603 my $self = {};
604 return bless($self, $class)->bigbang();
605 }
606 1;
607 Because we were careful to be good little creators when we designed our
609 Cosmos class, we can now reuse it without touching a single line of
610 code when it comes time to write our Multiverse class. The same code
611 that worked when invoked as a class method continues to work perfectly
612 well when invoked against separate instances of a derived class.
613 The astonishing thing about the Cosmos class above is that the value
615 returned by the &bigbang "constructor" is not a reference to a blessed
616 object at all. It's just the class's own name. A class name is, for
617 virtually all intents and purposes, a perfectly acceptable object. It
618 has state, behavior, and identity, the three crucial components of an
619 object system. It even manifests inheritance, polymorphism, and encap‐
620 sulation. And what more can you ask of an object?
621 To understand object orientation in Perl, it's important to recognize
623 the unification of what other programming languages might think of as
624 class methods and object methods into just plain methods. "Class meth‐
625 ods" and "object methods" are distinct only in the compartmentalizing
626 mind of the Perl programmer, not in the Perl language itself.
627 Along those same lines, a constructor is nothing special either, which
629 is one reason why Perl has no pre-ordained name for them. "Construc‐
630 tor" is just an informal term loosely used to describe a method that
631 returns a scalar value that you can make further method calls against.
632 So long as it's either a class name or an object reference, that's good
633 enough. It doesn't even have to be a reference to a brand new object.
634 You can have as many--or as few--constructors as you want, and you can
636 name them whatever you care to. Blindly and obediently using new() for
637 each and every constructor you ever write is to speak Perl with such a
638 severe C++ accent that you do a disservice to both languages. There's
639 no reason to insist that each class have but one constructor, or that a
640 constructor be named new(), or that a constructor be used solely as a
641 class method and not an object method.
642 The next section shows how useful it can be to further distance our‐
644 selves from any formal distinction between class method calls and
645 object method calls, both in constructors and in accessor methods.
646 Translucent Attributes
648 A package's eponymous hash can be used for more than just containing
650 per-class, global state data. It can also serve as a sort of template
651 containing default settings for object attributes. These default set‐
652 tings can then be used in constructors for initialization of a particu‐
653 lar object. The class's eponymous hash can also be used to implement
654 translucent attributes. A translucent attribute is one that has a
655 class-wide default. Each object can set its own value for the
656 attribute, in which case "$object->attribute()" returns that value.
657 But if no value has been set, then "$object->attribute()" returns the
658 class-wide default.
659 We'll apply something of a copy-on-write approach to these translucent
661 attributes. If you're just fetching values from them, you get translu‐
662 cency. But if you store a new value to them, that new value is set on
663 the current object. On the other hand, if you use the class as an
664 object and store the attribute value directly on the class, then the
665 meta-object's value changes, and later fetch operations on objects with
666 uninitialized values for those attributes will retrieve the
667 meta-object's new values. Objects with their own initialized values,
668 however, won't see any change.
669 Let's look at some concrete examples of using these properties before
671 we show how to implement them. Suppose that a class named Some_Class
672 had a translucent data attribute called "color". First you set the
673 color in the meta-object, then you create three objects using a con‐
674 structor that happens to be named &spawn.
675 use Vermin;
677 Vermin->color("vermilion");
678 $ob1 = Vermin->spawn(); # so that's where Jedi come from
680 $ob2 = Vermin->spawn();
681 $ob3 = Vermin->spawn();
682 print $obj3->color(); # prints "vermilion"
684 Each of these objects' colors is now "vermilion", because that's the
686 meta-object's value for that attribute, and these objects do not have
687 individual color values set.
688 Changing the attribute on one object has no effect on other objects
690 previously created.
691 $ob3->color("chartreuse");
693 print $ob3->color(); # prints "chartreuse"
694 print $ob1->color(); # prints "vermilion", translucently
695 If you now use $ob3 to spawn off another object, the new object will
697 take the color its parent held, which now happens to be "chartreuse".
698 That's because the constructor uses the invoking object as its template
699 for initializing attributes. When that invoking object is the class
700 name, the object used as a template is the eponymous meta-object. When
701 the invoking object is a reference to an instantiated object, the
702 &spawn constructor uses that existing object as a template.
703 $ob4 = $ob3->spawn(); # $ob3 now template, not %Vermin
705 print $ob4->color(); # prints "chartreuse"
706 Any actual values set on the template object will be copied to the new
708 object. But attributes undefined in the template object, being
709 translucent, will remain undefined and consequently translucent in the
710 new one as well.
711 Now let's change the color attribute on the entire class:
713 Vermin->color("azure");
715 print $ob1->color(); # prints "azure"
716 print $ob2->color(); # prints "azure"
717 print $ob3->color(); # prints "chartreuse"
718 print $ob4->color(); # prints "chartreuse"
719 That color change took effect only in the first pair of objects, which
721 were still translucently accessing the meta-object's values. The sec‐
722 ond pair had per-object initialized colors, and so didn't change.
723 One important question remains. Changes to the meta-object are
725 reflected in translucent attributes in the entire class, but what about
726 changes to discrete objects? If you change the color of $ob3, does the
727 value of $ob4 see that change? Or vice-versa. If you change the color
728 of $ob4, does then the value of $ob3 shift?
729 $ob3->color("amethyst");
731 print $ob3->color(); # prints "amethyst"
732 print $ob4->color(); # hmm: "chartreuse" or "amethyst"?
733 While one could argue that in certain rare cases it should, let's not
735 do that. Good taste aside, we want the answer to the question posed in
736 the comment above to be "chartreuse", not "amethyst". So we'll treat
737 these attributes similar to the way process attributes like environment
738 variables, user and group IDs, or the current working directory are
739 treated across a fork(). You can change only yourself, but you will
740 see those changes reflected in your unspawned children. Changes to one
741 object will propagate neither up to the parent nor down to any existing
742 child objects. Those objects made later, however, will see the
743 changes.
744 If you have an object with an actual attribute value, and you want to
746 make that object's attribute value translucent again, what do you do?
747 Let's design the class so that when you invoke an accessor method with
748 "undef" as its argument, that attribute returns to translucency.
749 $ob4->color(undef); # back to "azure"
751 Here's a complete implementation of Vermin as described above.
753 package Vermin;
755 # here's the class meta-object, eponymously named.
757 # it holds all class attributes, and also all instance attributes
758 # so the latter can be used for both initialization
759 # and translucency.
760 our %Vermin = ( # our() is new to perl5.6
762 PopCount => 0, # capital for class attributes
763 color => "beige", # small for instance attributes
764 );
765 # constructor method
767 # invoked as class method or object method
768 sub spawn {
769 my $obclass = shift;
770 my $class = ref($obclass) ⎪⎪ $obclass;
771 my $self = {};
772 bless($self, $class);
773 $class->{PopCount}++;
774 # init fields from invoking object, or omit if
775 # invoking object is the class to provide translucency
776 %$self = %$obclass if ref $obclass;
777 return $self;
778 }
779 # translucent accessor for "color" attribute
781 # invoked as class method or object method
782 sub color {
783 my $self = shift;
784 my $class = ref($self) ⎪⎪ $self;
785 # handle class invocation
787 unless (ref $self) {
788 $class->{color} = shift if @_;
789 return $class->{color}
790 }
791 # handle object invocation
793 $self->{color} = shift if @_;
794 if (defined $self->{color}) { # not exists!
795 return $self->{color};
796 } else {
797 return $class->{color};
798 }
799 }
800 # accessor for "PopCount" class attribute
802 # invoked as class method or object method
803 # but uses object solely to locate meta-object
804 sub population {
805 my $obclass = shift;
806 my $class = ref($obclass) ⎪⎪ $obclass;
807 return $class->{PopCount};
808 }
809 # instance destructor
811 # invoked only as object method
812 sub DESTROY {
813 my $self = shift;
814 my $class = ref $self;
815 $class->{PopCount}--;
816 }
817 Here are a couple of helper methods that might be convenient. They
819 aren't accessor methods at all. They're used to detect accessibility
820 of data attributes. The &is_translucent method determines whether a
821 particular object attribute is coming from the meta-object. The
822 &has_attribute method detects whether a class implements a particular
823 property at all. It could also be used to distinguish undefined prop‐
824 erties from non-existent ones.
825 # detect whether an object attribute is translucent
827 # (typically?) invoked only as object method
828 sub is_translucent {
829 my($self, $attr) = @_;
830 return !defined $self->{$attr};
831 }
832 # test for presence of attribute in class
834 # invoked as class method or object method
835 sub has_attribute {
836 my($self, $attr) = @_;
837 my $class = ref($self) ⎪⎪ $self;
838 return exists $class->{$attr};
839 }
840 If you prefer to install your accessors more generically, you can make
842 use of the upper-case versus lower-case convention to register into the
843 package appropriate methods cloned from generic closures.
844 for my $datum (keys %{ +__PACKAGE__ }) {
846 *$datum = ($datum =~ /^[A-Z]/)
847 ? sub { # install class accessor
848 my $obclass = shift;
849 my $class = ref($obclass) ⎪⎪ $obclass;
850 return $class->{$datum};
851 }
852 : sub { # install translucent accessor
853 my $self = shift;
854 my $class = ref($self) ⎪⎪ $self;
855 unless (ref $self) {
856 $class->{$datum} = shift if @_;
857 return $class->{$datum}
858 }
859 $self->{$datum} = shift if @_;
860 return defined $self->{$datum}
861 ? $self -> {$datum}
862 : $class -> {$datum}
863 }
864 }
865 Translations of this closure-based approach into C++, Java, and Python
867 have been left as exercises for the reader. Be sure to send us mail as
868 soon as you're done.
869
871 Privacy and Responsibility
872 Unlike conventions used by some Perl programmers, in the previous exam‐
874 ples, we didn't prefix the package variables used for class attributes
875 with an underscore, nor did we do so for the names of the hash keys
876 used for instance attributes. You don't need little markers on data
877 names to suggest nominal privacy on attribute variables or hash keys,
878 because these are already notionally private! Outsiders have no busi‐
879 ness whatsoever playing with anything within a class save through the
880 mediated access of its documented interface; in other words, through
881 method invocations. And not even through just any method, either.
882 Methods that begin with an underscore are traditionally considered off-
883 limits outside the class. If outsiders skip the documented method
884 interface to poke around the internals of your class and end up break‐
885 ing something, that's not your fault--it's theirs.
886 Perl believes in individual responsibility rather than mandated con‐
888 trol. Perl respects you enough to let you choose your own preferred
889 level of pain, or of pleasure. Perl believes that you are creative,
890 intelligent, and capable of making your own decisions--and fully
891 expects you to take complete responsibility for your own actions. In a
892 perfect world, these admonitions alone would suffice, and everyone
893 would be intelligent, responsible, happy, and creative. And careful.
894 One probably shouldn't forget careful, and that's a good bit harder to
895 expect. Even Einstein would take wrong turns by accident and end up
896 lost in the wrong part of town.
897 Some folks get the heebie-jeebies when they see package variables hang‐
899 ing out there for anyone to reach over and alter them. Some folks live
900 in constant fear that someone somewhere might do something wicked. The
901 solution to that problem is simply to fire the wicked, of course. But
902 unfortunately, it's not as simple as all that. These cautious types
903 are also afraid that they or others will do something not so much
904 wicked as careless, whether by accident or out of desperation. If we
905 fire everyone who ever gets careless, pretty soon there won't be any‐
906 body left to get any work done.
907 Whether it's needless paranoia or sensible caution, this uneasiness can
909 be a problem for some people. We can take the edge off their discom‐
910 fort by providing the option of storing class attributes as lexical
911 variables instead of as package variables. The my() operator is the
912 source of all privacy in Perl, and it is a powerful form of privacy
913 indeed.
914 It is widely perceived, and indeed has often been written, that Perl
916 provides no data hiding, that it affords the class designer no privacy
917 nor isolation, merely a rag-tag assortment of weak and unenforceable
918 social conventions instead. This perception is demonstrably false and
919 easily disproven. In the next section, we show how to implement forms
920 of privacy that are far stronger than those provided in nearly any
921 other object-oriented language.
922 File-Scoped Lexicals
924 A lexical variable is visible only through the end of its static scope.
926 That means that the only code able to access that variable is code
927 residing textually below the my() operator through the end of its block
928 if it has one, or through the end of the current file if it doesn't.
929 Starting again with our simplest example given at the start of this
931 document, we replace our() variables with my() versions.
932 package Some_Class;
934 my($CData1, $CData2); # file scope, not in any package
935 sub CData1 {
936 shift; # XXX: ignore calling class/object
937 $CData1 = shift if @_;
938 return $CData1;
939 }
940 sub CData2 {
941 shift; # XXX: ignore calling class/object
942 $CData2 = shift if @_;
943 return $CData2;
944 }
945 So much for that old $Some_Class::CData1 package variable and its
947 brethren! Those are gone now, replaced with lexicals. No one outside
948 the scope can reach in and alter the class state without resorting to
949 the documented interface. Not even subclasses or superclasses of this
950 one have unmediated access to $CData1. They have to invoke the &CData1
951 method against Some_Class or an instance thereof, just like anybody
952 else.
953 To be scrupulously honest, that last statement assumes you haven't
955 packed several classes together into the same file scope, nor strewn
956 your class implementation across several different files. Accessibil‐
957 ity of those variables is based uniquely on the static file scope. It
958 has nothing to do with the package. That means that code in a differ‐
959 ent file but the same package (class) could not access those variables,
960 yet code in the same file but a different package (class) could. There
961 are sound reasons why we usually suggest a one-to-one mapping between
962 files and packages and modules and classes. You don't have to stick to
963 this suggestion if you really know what you're doing, but you're apt to
964 confuse yourself otherwise, especially at first.
965 If you'd like to aggregate your class attributes into one lexically
967 scoped, composite structure, you're perfectly free to do so.
968 package Some_Class;
970 my %ClassData = (
971 CData1 => "",
972 CData2 => "",
973 );
974 sub CData1 {
975 shift; # XXX: ignore calling class/object
976 $ClassData{CData1} = shift if @_;
977 return $ClassData{CData1};
978 }
979 sub CData2 {
980 shift; # XXX: ignore calling class/object
981 $ClassData{CData2} = shift if @_;
982 return $ClassData{CData2};
983 }
984 To make this more scalable as other class attributes are added, we can
986 again register closures into the package symbol table to create acces‐
987 sor methods for them.
988 package Some_Class;
990 my %ClassData = (
991 CData1 => "",
992 CData2 => "",
993 );
994 for my $datum (keys %ClassData) {
995 no strict "refs";
996 *$datum = sub {
997 shift; # XXX: ignore calling class/object
998 $ClassData{$datum} = shift if @_;
999 return $ClassData{$datum};
1000 };
1001 }
1002 Requiring even your own class to use accessor methods like anybody else
1004 is probably a good thing. But demanding and expecting that everyone
1005 else, be they subclass or superclass, friend or foe, will all come to
1006 your object through mediation is more than just a good idea. It's
1007 absolutely critical to the model. Let there be in your mind no such
1008 thing as "public" data, nor even "protected" data, which is a seductive
1009 but ultimately destructive notion. Both will come back to bite at you.
1010 That's because as soon as you take that first step out of the solid
1011 position in which all state is considered completely private, save from
1012 the perspective of its own accessor methods, you have violated the
1013 envelope. And, having pierced that encapsulating envelope, you shall
1014 doubtless someday pay the price when future changes in the implementa‐
1015 tion break unrelated code. Considering that avoiding this infelicitous
1016 outcome was precisely why you consented to suffer the slings and arrows
1017 of obsequious abstraction by turning to object orientation in the first
1018 place, such breakage seems unfortunate in the extreme.
1019 More Inheritance Concerns
1021 Suppose that Some_Class were used as a base class from which to derive
1023 Another_Class. If you invoke a &CData method on the derived class or
1024 on an object of that class, what do you get? Would the derived class
1025 have its own state, or would it piggyback on its base class's versions
1026 of the class attributes?
1027 The answer is that under the scheme outlined above, the derived class
1029 would not have its own state data. As before, whether you consider
1030 this a good thing or a bad one depends on the semantics of the classes
1031 involved.
1032 The cleanest, sanest, simplest way to address per-class state in a lex‐
1034 ical is for the derived class to override its base class's version of
1035 the method that accesses the class attributes. Since the actual method
1036 called is the one in the object's derived class if this exists, you
1037 automatically get per-class state this way. Any urge to provide an
1038 unadvertised method to sneak out a reference to the %ClassData hash
1039 should be strenuously resisted.
1040 As with any other overridden method, the implementation in the derived
1042 class always has the option of invoking its base class's version of the
1043 method in addition to its own. Here's an example:
1044 package Another_Class;
1046 @ISA = qw(Some_Class);
1047 my %ClassData = (
1049 CData1 => "",
1050 );
1051 sub CData1 {
1053 my($self, $newvalue) = @_;
1054 if (@_ > 1) {
1055 # set locally first
1056 $ClassData{CData1} = $newvalue;
1057 # then pass the buck up to the first
1059 # overridden version, if there is one
1060 if ($self->can("SUPER::CData1")) {
1061 $self->SUPER::CData1($newvalue);
1062 }
1063 }
1064 return $ClassData{CData1};
1065 }
1066 Those dabbling in multiple inheritance might be concerned about there
1068 being more than one override.
1069 for my $parent (@ISA) {
1071 my $methname = $parent . "::CData1";
1072 if ($self->can($methname)) {
1073 $self->$methname($newvalue);
1074 }
1075 }
1076 Because the &UNIVERSAL::can method returns a reference to the function
1078 directly, you can use this directly for a significant performance
1079 improvement:
1080 for my $parent (@ISA) {
1082 if (my $coderef = $self->can($parent . "::CData1")) {
1083 $self->$coderef($newvalue);
1084 }
1085 }
1086 If you override "UNIVERSAL::can" in your own classes, be sure to return
1088 the reference appropriately.
1089 Locking the Door and Throwing Away the Key
1091 As currently implemented, any code within the same scope as the file-
1093 scoped lexical %ClassData can alter that hash directly. Is that ok?
1094 Is it acceptable or even desirable to allow other parts of the imple‐
1095 mentation of this class to access class attributes directly?
1096 That depends on how careful you want to be. Think back to the Cosmos
1098 class. If the &supernova method had directly altered $Cosmos::Stars or
1099 $Cosmos::Cosmos{stars}, then we wouldn't have been able to reuse the
1100 class when it came to inventing a Multiverse. So letting even the
1101 class itself access its own class attributes without the mediating
1102 intervention of properly designed accessor methods is probably not a
1103 good idea after all.
1104 Restricting access to class attributes from the class itself is usually
1106 not enforceable even in strongly object-oriented languages. But in
1107 Perl, you can.
1108 Here's one way:
1110 package Some_Class;
1112 { # scope for hiding $CData1
1114 my $CData1;
1115 sub CData1 {
1116 shift; # XXX: unused
1117 $CData1 = shift if @_;
1118 return $CData1;
1119 }
1120 }
1121 { # scope for hiding $CData2
1123 my $CData2;
1124 sub CData2 {
1125 shift; # XXX: unused
1126 $CData2 = shift if @_;
1127 return $CData2;
1128 }
1129 }
1130 No one--absolutely no one--is allowed to read or write the class
1132 attributes without the mediation of the managing accessor method, since
1133 only that method has access to the lexical variable it's managing.
1134 This use of mediated access to class attributes is a form of privacy
1135 far stronger than most OO languages provide.
1136 The repetition of code used to create per-datum accessor methods chafes
1138 at our Laziness, so we'll again use closures to create similar methods.
1139 package Some_Class;
1141 { # scope for ultra-private meta-object for class attributes
1143 my %ClassData = (
1144 CData1 => "",
1145 CData2 => "",
1146 );
1147 for my $datum (keys %ClassData ) {
1149 no strict "refs";
1150 *$datum = sub {
1151 use strict "refs";
1152 my ($self, $newvalue) = @_;
1153 $ClassData{$datum} = $newvalue if @_ > 1;
1154 return $ClassData{$datum};
1155 }
1156 }
1157 }
1159 The closure above can be modified to take inheritance into account
1161 using the &UNIVERSAL::can method and SUPER as shown previously.
1162 Translucency Revisited
1164 The Vermin class demonstrates translucency using a package variable,
1166 eponymously named %Vermin, as its meta-object. If you prefer to use
1167 absolutely no package variables beyond those necessary to appease
1168 inheritance or possibly the Exporter, this strategy is closed to you.
1169 That's too bad, because translucent attributes are an appealing tech‐
1170 nique, so it would be valuable to devise an implementation using only
1171 lexicals.
1172 There's a second reason why you might wish to avoid the eponymous pack‐
1174 age hash. If you use class names with double-colons in them, you would
1175 end up poking around somewhere you might not have meant to poke.
1176 package Vermin;
1178 $class = "Vermin";
1179 $class->{PopCount}++;
1180 # accesses $Vermin::Vermin{PopCount}
1181 package Vermin::Noxious;
1183 $class = "Vermin::Noxious";
1184 $class->{PopCount}++;
1185 # accesses $Vermin::Noxious{PopCount}
1186 In the first case, because the class name had no double-colons, we got
1188 the hash in the current package. But in the second case, instead of
1189 getting some hash in the current package, we got the hash %Noxious in
1190 the Vermin package. (The noxious vermin just invaded another package
1191 and sprayed their data around it. :-) Perl doesn't support relative
1192 packages in its naming conventions, so any double-colons trigger a
1193 fully-qualified lookup instead of just looking in the current package.
1194 In practice, it is unlikely that the Vermin class had an existing pack‐
1196 age variable named %Noxious that you just blew away. If you're still
1197 mistrustful, you could always stake out your own territory where you
1198 know the rules, such as using Eponymous::Vermin::Noxious or Hierony‐
1199 mus::Vermin::Boschious or Leave_Me_Alone::Vermin::Noxious as class
1200 names instead. Sure, it's in theory possible that someone else has a
1201 class named Eponymous::Vermin with its own %Noxious hash, but this kind
1202 of thing is always true. There's no arbiter of package names. It's
1203 always the case that globals like @Cwd::ISA would collide if more than
1204 one class uses the same Cwd package.
1205 If this still leaves you with an uncomfortable twinge of paranoia, we
1207 have another solution for you. There's nothing that says that you have
1208 to have a package variable to hold a class meta-object, either for
1209 monadic classes or for translucent attributes. Just code up the meth‐
1210 ods so that they access a lexical instead.
1211 Here's another implementation of the Vermin class with semantics iden‐
1213 tical to those given previously, but this time using no package vari‐
1214 ables.
1215 package Vermin;
1217 # Here's the class meta-object, eponymously named.
1219 # It holds all class data, and also all instance data
1220 # so the latter can be used for both initialization
1221 # and translucency. it's a template.
1222 my %ClassData = (
1223 PopCount => 0, # capital for class attributes
1224 color => "beige", # small for instance attributes
1225 );
1226 # constructor method
1228 # invoked as class method or object method
1229 sub spawn {
1230 my $obclass = shift;
1231 my $class = ref($obclass) ⎪⎪ $obclass;
1232 my $self = {};
1233 bless($self, $class);
1234 $ClassData{PopCount}++;
1235 # init fields from invoking object, or omit if
1236 # invoking object is the class to provide translucency
1237 %$self = %$obclass if ref $obclass;
1238 return $self;
1239 }
1240 # translucent accessor for "color" attribute
1242 # invoked as class method or object method
1243 sub color {
1244 my $self = shift;
1245 # handle class invocation
1247 unless (ref $self) {
1248 $ClassData{color} = shift if @_;
1249 return $ClassData{color}
1250 }
1251 # handle object invocation
1253 $self->{color} = shift if @_;
1254 if (defined $self->{color}) { # not exists!
1255 return $self->{color};
1256 } else {
1257 return $ClassData{color};
1258 }
1259 }
1260 # class attribute accessor for "PopCount" attribute
1262 # invoked as class method or object method
1263 sub population {
1264 return $ClassData{PopCount};
1265 }
1266 # instance destructor; invoked only as object method
1268 sub DESTROY {
1269 $ClassData{PopCount}--;
1270 }
1271 # detect whether an object attribute is translucent
1273 # (typically?) invoked only as object method
1274 sub is_translucent {
1275 my($self, $attr) = @_;
1276 $self = \%ClassData if !ref $self;
1277 return !defined $self->{$attr};
1278 }
1279 # test for presence of attribute in class
1281 # invoked as class method or object method
1282 sub has_attribute {
1283 my($self, $attr) = @_;
1284 return exists $ClassData{$attr};
1285 }
1286
1288 Inheritance is a powerful but subtle device, best used only after care‐
1289 ful forethought and design. Aggregation instead of inheritance is
1290 often a better approach.
1291 You can't use file-scoped lexicals in conjunction with the SelfLoader
1293 or the AutoLoader, because they alter the lexical scope in which the
1294 module's methods wind up getting compiled.
1295 The usual mealy-mouthed package-munging doubtless applies to setting up
1297 names of object attributes. For example, "$self->{ObData1}" should
1298 probably be "$self->{ __PACKAGE__ . "_ObData1" }", but that would just
1299 confuse the examples.
1300
1302 perltoot, perlobj, perlmod, and perlbot.
1303 The Tie::SecureHash and Class::Data::Inheritable modules from CPAN are
1305 worth checking out.
1306
1308 Copyright (c) 1999 Tom Christiansen. All rights reserved.
1309 This documentation is free; you can redistribute it and/or modify it
1311 under the same terms as Perl itself.
1312 Irrespective of its distribution, all code examples in this file are
1314 hereby placed into the public domain. You are permitted and encouraged
1315 to use this code in your own programs for fun or for profit as you see
1316 fit. A simple comment in the code giving credit would be courteous but
1317 is not required.
1318
1320 Russ Allbery, Jon Orwant, Randy Ray, Larry Rosler, Nat Torkington, and
1321 Stephen Warren all contributed suggestions and corrections to this
1322 piece. Thanks especially to Damian Conway for his ideas and feedback,
1323 and without whose indirect prodding I might never have taken the time
1324 to show others how much Perl has to offer in the way of objects once
1325 you start thinking outside the tiny little box that today's "popular"
1326 object-oriented languages enforce.
1327
1329 Last edit: Sun Feb 4 20:50:28 EST 2001
1330perl v5.8.8 2006-01-07 PERLTOOC(1)