Penguin
Recent Changes
Blame: perltootc(1)
EditPageHistoryDiffInfoLikePages
Annotated edit history of perltootc(1) version 2 showing authors affecting page license. View with all changes included.
Rev Author # Line
1 perry 1 PERLTOOTC
2 !!!PERLTOOTC
3 NAME
4 DESCRIPTION
5 Class Data in a Can
6 Class Data as Package Variables
7 Class Data as Lexical Variables
8 NOTES
9 SEE ALSO
10 AUTHOR AND COPYRIGHT
11 ACKNOWLEDGEMENTS
12 HISTORY
13 ----
14 !!NAME
15
16
17 perltootc - Tom's OO Tutorial for Class Data in Perl
18 !!DESCRIPTION
19
20
21 When designing an object class, you are sometimes faced with
22 the situation of wanting common state shared by all objects
23 of that class. Such ''class attributes'' act somewhat
24 like global variables for the entire class, but unlike
25 program-wide globals, class attributes have meaning only to
26 the class itself.
27
28
29 Here are a few examples where class attributes might come in
30 handy:
31
32
33 to keep a count of the objects you've created, or how many
34 are still extant.
35
36
37 to extract the name or file descriptor for a logfile used by
38 a debugging method.
39
40
41 to access collective data, like the total amount of cash
42 dispensed by all ATMs in a network in a given
43 day.
44
45
46 to access the last object created by a class, or the most
47 accessed object, or to retrieve a list of all
48 objects.
49
50
51 Unlike a true global, class attributes should not be
52 accessed directly. Instead, their state should be inspected,
53 and perhaps altered, only through the mediated access of
54 ''class methods''. These class attributes accessor
55 methods are similar in spirit and function to accessors used
56 to manipulate the state of instance attributes on an object.
57 They provide a clear firewall between interface and
58 implementation.
59
60
61 You should allow access to class attributes through either
62 the class name or any object of that class. If we assume
63 that $an_object is of type Some_Class, and the
64
65
66 Some_Class-
67 The question is, where do you store the state which that method accesses? Unlike more restrictive languages like C ++ , where these are called static data members, Perl provides no syntactic mechanism to declare class attributes, any more than it provides a syntactic mechanism to declare instance attributes. Perl provides the developer with a broad set of powerful but flexible features that can be uniquely crafted to the particular demands of the situation.
68
69
70 A class in Perl is typically implemented in a module. A
71 module consists of two complementary feature sets: a package
72 for interfacing with the outside world, and a lexical file
73 scope for privacy. Either of these two mechanisms can be
74 used to implement class attributes. That means you get to
75 decide whether to put your class attributes in package
76 variables or to put them in lexical variables.
77
78
79 And those aren't the only decisions to make. If you choose
80 to use package variables, you can make your class attribute
81 accessor methods either ignorant of inheritance or sensitive
82 to it. If you choose lexical variables, you can elect to
83 permit access to them from anywhere in the entire file
84 scope, or you can limit direct data access exclusively to
85 the methods implementing those attributes.
86 !!Class Data in a Can
87
88
89 One of the easiest ways to solve a hard problem is to let
90 someone else do it for you! In this case,
91 Class::Data::Inheritable (available on a CPAN
92 near you) offers a canned solution to the class data problem
93 using closures. So before you wade into this document,
94 consider having a look at that module.
95 !!Class Data as Package Variables
96
97
98 Because a class in Perl is really just a package, using
99 package variables to hold class attributes is the most
100 natural choice. This makes it simple for each class to have
101 its own class attributes. Let's say you have a class called
102 Some_Class that needs a couple of different attributes that
103 you'd like to be global to the entire class. The simplest
104 thing to do is to use package variables like
105 $Some_Class::CData1 and
106 $Some_Class::CData2 to hold these attributes. But
107 we certainly don't want to encourage outsiders to touch
108 those data directly, so we provide methods to mediate
109 access.
110
111
112 In the accessor methods below, we'll for now just ignore the
113 first argument--that part to the left of the arrow on method
114 invocation, which is either a class name or an object
115 reference.
116
117
118 package Some_Class;
119 sub CData1 {
120 shift; # XXX: ignore calling class/object
121 $Some_Class::CData1 = shift if @_;
122 return $Some_Class::CData1;
123 }
124 sub CData2 {
125 shift; # XXX: ignore calling class/object
126 $Some_Class::CData2 = shift if @_;
127 return $Some_Class::CData2;
128 }
129 This technique is highly legible and should be completely straightforward to even the novice Perl programmer. By fully qualifying the package variables, they stand out clearly when reading the code. Unfortunately, if you misspell one of these, you've introduced an error that's hard to catch. It's also somewhat disconcerting to see the class name itself hard-coded in so many places.
130
131
132 Both these problems can be easily fixed. Just add the
133 use strict pragma, then pre-declare your package
134 variables. (The our operator will be new in 5.6,
135 and will work for package globals just like my
136 works for scoped lexicals.)
137
138
139 package Some_Class;
140 use strict;
141 our($CData1, $CData2); # our() is new to perl5.6
142 sub CData1 {
143 shift; # XXX: ignore calling class/object
144 $CData1 = shift if @_;
145 return $CData1;
146 }
147 sub CData2 {
148 shift; # XXX: ignore calling class/object
149 $CData2 = shift if @_;
150 return $CData2;
151 }
152 As with any other global variable, some programmers prefer to start their package variables with capital letters. This helps clarity somewhat, but by no longer fully qualifying the package variables, their significance can be lost when reading the code. You can fix this easily enough by choosing better names than were used here.
153
154
155 __Putting All Your Eggs in One Basket__
156
157
158 Just as the mindless enumeration of accessor methods for
159 instance attributes grows tedious after the first few (see
160 perltoot), so too does the repetition begin to grate when
161 listing out accessor methods for class data. Repetition runs
162 counter to the primary virtue of a programmer: Laziness,
163 here manifesting as that innate urge every programmer feels
164 to factor out duplicate code whenever possible.
165
166
167 Here's what to do. First, make just one hash to hold all
168 class attributes.
169
170
171 package Some_Class;
172 use strict;
173 our %!ClassData = ( # our() is new to perl5.6
174 CData1 =
175 Using closures (see perlref) and direct access to the package symbol table (see perlmod), now clone an accessor method for each key in the %!ClassData hash. Each of these methods is used to fetch or store values to the specific, named class attribute.
176
177
178 for my $datum (keys %!ClassData) {
179 no strict
180 It's true that you could work out a solution employing an DESTROY . Such complexity is uncalled for in most cases, and certainly in this one.
181
182
183 You may wonder why we're rescinding strict refs for the
184 loop. We're manipulating the package's symbol table to
185 introduce new function names using symbolic references
186 (indirect naming), which the strict pragma would otherwise
187 forbid. Normally, symbolic references are a dodgy notion at
188 best. This isn't just because they can be used accidentally
189 when you aren't meaning to. It's also because for most uses
190 to which beginning Perl programmers attempt to put symbolic
191 references, we have much better approaches, like nested
192 hashes or hashes of arrays. But there's nothing wrong with
193 using symbolic references to manipulate something that is
194 meaningful only from the perspective of the package symbol
195 table, like method names or package variables. In other
196 words, when you want to refer to the symbol table, use
197 symbol references.
198
199
200 Clustering all the class attributes in one place has several
201 advantages. They're easy to spot, initialize, and change.
202 The aggregation also makes them convenient to access
203 externally, such as from a debugger or a persistence
204 package. The only possible problem is that we don't
205 automatically know the name of each class's class object,
206 should it have one. This issue is addressed below in ``The
207 Eponymous Meta-Object''.
208
209
210 __Inheritance Concerns__
211
212
213 Suppose you have an instance of a derived class, and you
214 access class data using an inherited method call. Should
215 that end up referring to the base class's attributes, or to
216 those in the derived class? How would it work in the earlier
217 examples? The derived class inherits all the base class's
218 methods, including those that access class attributes. But
219 what package are the class attributes stored
220 in?
221
222
223 The answer is that, as written, class attributes are stored
224 in the package into which those methods were compiled. When
225 you invoke the
226 $Some_Class::CData1--or in the method cloning
227 version,
228 $Some_Class::!ClassData{CData1}.
229
230
231 Think of these class methods as executing in the context of
232 their base class, not in that of their derived class.
233 Sometimes this is exactly what you want. If Feline
234 subclasses Carnivore, then the population of Carnivores in
235 the world should go up when a new Feline is born. But what
236 if you wanted to figure out how many Felines you have apart
237 from Carnivores? The current approach doesn't support
238 that.
239
240
241 You'll have to decide on a case-by-case basis whether it
242 makes any sense for class attributes to be package-relative.
243 If you want it to be so, then stop ignoring the first
244 argument to the function. Either it will be a package name
245 if the method was invoked directly on a class name, or else
246 it will be an object reference if the method was invoked on
247 an object reference. In the latter case, the ''ref()''
248 function provides the class of that object.
249
250
251 package Some_Class;
252 sub CData1 {
253 my $obclass = shift;
254 my $class = ref($obclass) $obclass;
255 my $varname = $class .
256 And then do likewise for all other class attributes (such as CData2, etc.) that you wish to access as package variables in the invoking package instead of the compiling package as we had previously.
257
258
259 Once again we temporarily disable the strict references ban,
260 because otherwise we couldn't use the fully-qualified
261 symbolic name for the package global. This is perfectly
262 reasonable: since all package variables by definition live
263 in a package, there's nothing wrong with accessing them via
264 that package's symbol table. That's what it's there for
265 (well, somewhat).
266
267
268 What about just using a single hash for everything and then
269 cloning methods? What would that look like? The only
270 difference would be the closure used to produce new method
271 entries for the class's symbol table.
272
273
274 no strict
275
276
277 __The Eponymous Meta-Object__
278
279
280 It could be argued that the %!ClassData hash in the
281 previous example is neither the most imaginative nor the
282 most intuitive of names. Is there something else that might
283 make more sense, be more useful, or both?
284
285
286 As it happens, yes, there is. For the ``class meta-object'',
287 we'll use a package variable of the same name as the package
288 itself. Within the scope of a package Some_Class
289 declaration, we'll use the eponymously named hash
290 %Some_Class as that class's meta-object. (Using an
291 eponymously named hash is somewhat reminiscent of classes
292 that name their constructors eponymously in the Python or C
293 ++ fashion. That is, class Some_Class would
294 use
295 The Perl Cookbook'' does this, if you're
296 looking for an example.)
297
298
299 This predictable approach has many benefits, including
300 having a well-known identifier to aid in debugging,
301 transparent persistence, or checkpointing. It's also the
302 obvious name for monadic classes and translucent attributes,
303 discussed later.
304
305
306 Here's an example of such a class. Notice how the name of
307 the hash storing the meta-object is the same as the name of
308 the package used to implement the class.
309
310
311 package Some_Class;
312 use strict;
313 # create class meta-object using that most perfect of names
314 our %Some_Class = ( # our() is new to perl5.6
315 CData1 =
316 # this accessor is calling-package-relative
317 sub CData1 {
318 my $obclass = shift;
319 my $class = ref($obclass) $obclass;
320 no strict
321 # but this accessor is not
322 sub CData2 {
323 shift; # XXX: ignore calling class/object
324 no strict
325 In the second accessor method, the __PACKAGE__ notation was used for two reasons. First, to avoid hardcoding the literal package name in the code in case we later want to change that name. Second, to clarify to the reader that what matters here is the package currently being compiled into, not the package of the invoking object or class. If the long sequence of non-alphabetic characters bothers you, you can always put the __PACKAGE__ in a variable first.
326
327
328 sub CData2 {
329 shift; # XXX: ignore calling class/object
330 no strict
331 Even though we're using symbolic references for good not evil, some folks tend to become unnerved when they see so many places with strict ref checking disabled. Given a symbolic reference, you can always produce a real reference (the reverse is not true, though). So we'll create a subroutine that does this conversion for us. If invoked as a function of no arguments, it returns a reference to the compiling class's eponymous hash. Invoked as a class method, it returns a reference to the eponymous hash of its caller. And when invoked as an object method, this function returns a reference to the eponymous hash for whatever class the object belongs to.
332
333
334 package Some_Class;
335 use strict;
336 our %Some_Class = ( # our() is new to perl5.6
337 CData1 =
338 # tri-natured: function, class method, or object method
339 sub _classobj {
340 my $obclass = shift __PACKAGE__;
341 my $class = ref($obclass) $obclass;
342 no strict
343 for my $datum (keys %{ _classobj() } ) {
344 # turn off strict refs so that we can
345 # register a method in the symbol table
346 no strict
347
348
349 __Indirect References to Class Data__
350
351
352 A reasonably common strategy for handling class attributes
353 is to store a reference to each package variable on the
354 object itself. This is a strategy you've probably seen
355 before, such as in perltoot and perlbot, but there may be
356 variations in the example below that you haven't thought of
357 before.
358
359
360 package Some_Class;
361 our($CData1, $CData2); # our() is new to perl5.6
362 sub new {
363 my $obclass = shift;
364 return bless my $self = {
365 ObData1 =
366 sub ObData1 {
367 my $self = shift;
368 $self-
369 sub ObData2 {
370 my $self = shift;
371 $self-
372 sub CData1 {
373 my $self = shift;
374 my $dataref = ref $self
375 ? $self-
376 sub CData2 {
377 my $self = shift;
378 my $dataref = ref $self
379 ? $self-
380 As written above, a derived class will inherit these methods, which will consequently access package variables in the base class's package. This is not necessarily expected behavior in all circumstances. Here's an example that uses a variable meta-object, taking care to access the proper package's data.
381
382
383 package Some_Class;
384 use strict;
385 our %Some_Class = ( # our() is new to perl5.6
386 CData1 =
387 sub _classobj {
388 my $self = shift;
389 my $class = ref($self) $self;
390 no strict
391 sub new {
392 my $obclass = shift;
393 my $classobj = $obclass-
394 sub ObData1 {
395 my $self = shift;
396 $self-
397 sub ObData2 {
398 my $self = shift;
399 $self-
400 sub CData1 {
401 my $self = shift;
402 $self = $self-
403 sub CData2 {
404 my $self = shift;
405 $self = $self-
406 Not only are we now strict refs clean, using an eponymous meta-object seems to make the code cleaner. Unlike the previous version, this one does something interesting in the face of inheritance: it accesses the class meta-object in the invoking class instead of the one into which the method was initially compiled.
407
408
409 You can easily access data in the class meta-object, making
410 it easy to dump the complete class state using an external
411 mechanism such as when debugging or implementing a
412 persistent class. This works because the class meta-object
413 is a package variable, has a well-known name, and clusters
414 all its data together. (Transparent persistence is not
415 always feasible, but it's certainly an appealing
416 idea.)
417
418
419 There's still no check that object accessor methods have not
420 been invoked on a class name. If strict ref checking is
421 enabled, you'd blow up. If not, then you get the eponymous
422 meta-object. What you do with--or about--this is up to you.
423 The next two sections demonstrate innovative uses for this
424 powerful feature.
425
426
427 __Monadic Classes__
428
429
430 Some of the standard modules shipped with Perl provide class
431 interfaces without any attribute methods whatsoever. The
432 most commonly used module not numbered amongst the pragmata,
433 the Exporter module, is a class with neither constructors
434 nor attributes. Its job is simply to provide a standard
435 interface for modules wishing to export part of their
436 namespace into that of their caller. Modules use the
437 Exporter's
438 @ISA array to mention
439 ``Exporter''. But class Exporter provides no constructor, so
440 you can't have several instances of the class. In fact, you
441 can't have any--it just doesn't make any sense. All you get
442 is its methods. Its interface contains no statefulness, so
443 state data is wholly superfluous.
444
445
446 Another sort of class that pops up from time to time is one
447 that supports a unique instance. Such classes are called
448 ''monadic classes'', or less formally, ''singletons''
449 or ''highlander classes''.
450
451
452 If a class is monadic, where do you store its state, that
453 is, its attributes? How do you make sure that there's never
454 more than one instance? While you could merely use a slew of
455 package variables, it's a lot cleaner to use the eponymously
456 named hash. Here's a complete example of a monadic
457 class:
458
459
460 package Cosmos;
461 %Cosmos = ();
462 # accessor method for
463 # read-only accessor method for
464 # accessor method for
465 # oh my - one of our stars just went out!
466 sub supernova {
467 my $self = shift;
468 my $count = $self-
469 # constructor/initializer method - fix by reboot
470 sub bigbang {
471 my $self = shift;
472 %$self = (
473 name =
474 # After the class is compiled, but before any use or require
475 # returns, we start off the universe with a bang.
476 __PACKAGE__ -
477 Hold on, that doesn't look like anything special. Those attribute accessors look no different than they would if this were a regular class instead of a monadic one. The crux of the matter is there's nothing that says that $self must hold a reference to a blessed object. It merely has to be something you can invoke methods on. Here the package name itself, Cosmos, works as an object. Look at the %$self is really accessing the %Cosmos package variable.
478
479
480 If like Stephen Hawking, you posit the existence of
481 multiple, sequential, and unrelated universes, then you can
482 invoke the
483
484
485 Imagine that some day in the future, you decide that one
486 universe just isn't enough. You could write a new class from
487 scratch, but you already have an existing class that does
488 what you want--except that it's monadic, and you want more
489 than just one cosmos.
490
491
492 That's what code reuse via subclassing is all about. Look
493 how short the new code is:
494
495
496 package Multiverse;
497 use Cosmos;
498 @ISA = qw(Cosmos);
499 sub new {
500 my $protoverse = shift;
501 my $class = ref($protoverse) $protoverse;
502 my $self = {};
503 return bless($self, $class)-
504 Because we were careful to be good little creators when we designed our Cosmos class, we can now reuse it without touching a single line of code when it comes time to write our Multiverse class. The same code that worked when invoked as a class method continues to work perfectly well when invoked against separate instances of a derived class.
505
506
507 The astonishing thing about the Cosmos class above is that
508 the value returned by the
509
510
511 To understand object orientation in Perl, it's important to
512 recognize the unification of what other programming
513 languages might think of as class methods and object methods
514 into just plain methods. ``Class methods'' and ``object
515 methods'' are distinct only in the compartmentalizing mind
516 of the Perl programmer, not in the Perl language
517 itself.
518
519
520 Along those same lines, a constructor is nothing special
521 either, which is one reason why Perl has no pre-ordained
522 name for them. ``Constructor'' is just an informal term
523 loosely used to describe a method that returns a scalar
524 value that you can make further method calls against. So
525 long as it's either a class name or an object reference,
526 that's good enough. It doesn't even have to be a reference
527 to a brand new object.
528
529
530 You can have as many--or as few--constructors as you want,
531 and you can name them whatever you care to. Blindly and
532 obediently using ''new()'' for each and every constructor
533 you ever write is to speak Perl with such a severe C
534 ++ accent that you do a disservice to both
535 languages. There's no reason to insist that each class have
536 but one constructor, or that that constructor be named
537 ''new()'', or that that constructor be used solely as a
538 class method and not an object method.
539
540
541 The next section shows how useful it can be to further
542 distance ourselves from any formal distinction between class
543 method calls and object method calls, both in constructors
544 and in accessor methods.
545
546
547 __Translucent Attributes__
548
549
550 A package's eponymous hash can be used for more than just
551 containing per-class, global state data. It can also serve
552 as a sort of template containing default settings for object
553 attributes. These default settings can then be used in
554 constructors for initialization of a particular object. The
555 class's eponymous hash can also be used to implement
556 ''translucent attributes''. A translucent attribute is
557 one that has a class-wide default. Each object can set its
558 own value for the attribute, in which case
559 $object- returns that value. But if
560 no value has been set, then $object-
561 returns the class-wide default.
562
563
564 We'll apply something of a copy-on-write approach to these
565 translucent attributes. If you're just fetching values from
566 them, you get translucency. But if you store a new value to
567 them, that new value is set on the current object. On the
568 other hand, if you use the class as an object and store the
569 attribute value directly on the class, then the
570 meta-object's value changes, and later fetch operations on
571 objects with uninitialized values for those attributes will
572 retrieve the meta-object's new values. Objects with their
573 own initialized values, however, won't see any
574 change.
575
576
577 Let's look at some concrete examples of using these
578 properties before we show how to implement them. Suppose
579 that a class named Some_Class had a translucent data
580 attribute called ``color''. First you set the color in the
581 meta-object, then you create three objects using a
582 constructor that happens to be named
583
584
585 use Vermin;
586 Vermin-
587 $ob1 = Vermin-
588 print $obj3-
589 Each of these objects' colors is now ``vermilion'', because that's the meta-object's value that attribute, and these objects do not have individual color values set.
590
591
592 Changing the attribute on one object has no effect on other
593 objects previously created.
594
595
596 $ob3-
597 If you now use $ob3 to spawn off another object, the new object will take the color its parent held, which now happens to be ``chartreuse''. That's because the constructor uses the invoking object as its template for initializing attributes. When that invoking object is the class name, the object used as a template is the eponymous meta-object. When the invoking object is a reference to an instantiated object, the
598
599
600 $ob4 = $ob3-
601 Any actual values set on the template object will be copied to the new object. But attributes undefined in the template object, being translucent, will remain undefined and consequently translucent in the new one as well.
602
603
604 Now let's change the color attribute on the entire
605 class:
606
607
608 Vermin-
609 That color change took effect only in the first pair of objects, which were still translucently accessing the meta-object's values. The second pair had per-object initialized colors, and so didn't change.
610
611
612 One important question remains. Changes to the meta-object
613 are reflected in translucent attributes in the entire class,
614 but what about changes to discrete objects? If you change
615 the color of $ob3, does the value of $ob4
616 see that change? Or vice-versa. If you change the color of
617 $ob4, does then the value of $ob3
618 shift?
619
620
621 $ob3-
622 While one could argue that in certain rare cases it should, let's not do that. Good taste aside, we want the answer to the question posed in the comment above to be ``chartreuse'', not ``amethyst''. So we'll treat these attributes similar to the way process attributes like environment variables, user and group IDs, or the current working directory are treated across a ''fork()''. You can change only yourself, but you will see those changes reflected in your unspawned children. Changes to one object will propagate neither up to the parent nor down to any existing child objects. Those objects made later, however, will see the changes.
623
624
625 If you have an object with an actual attribute value, and
626 you want to make that object's attribute value translucent
627 again, what do you do? Let's design the class so that when
628 you invoke an accessor method with undef as its
629 argument, that attribute returns to
630 translucency.
631
632
633 $ob4-
634 Here's a complete implementation of Vermin as described above.
635
636
637 package Vermin;
638 # here's the class meta-object, eponymously named.
639 # it holds all class attributes, and also all instance attributes
640 # so the latter can be used for both initialization
641 # and translucency.
642 our %Vermin = ( # our() is new to perl5.6
643 !PopCount =
644 # constructor method
645 # invoked as class method or object method
646 sub spawn {
647 my $obclass = shift;
648 my $class = ref($obclass) $obclass;
649 my $self = {};
650 bless($self, $class);
651 $class-
652 # translucent accessor for
653 # handle class invocation
654 unless (ref $self) {
655 $class-
656 # handle object invocation
657 $self-
658 # accessor for
659 # instance destructor
660 # invoked only as object method
661 sub DESTROY {
662 my $self = shift;
663 my $class = ref $self;
664 $class-
665 Here are a couple of helper methods that might be convenient. They aren't accessor methods at all. They're used to detect accessibility of data attributes. The
666
667
668 # detect whether an object attribute is translucent
669 # (typically?) invoked only as object method
670 sub is_translucent {
671 my($self, $attr) = @_;
672 return !defined $self-
673 # test for presence of attribute in class
674 # invoked as class method or object method
675 sub has_attribute {
676 my($self, $attr) = @_;
677 my $class = ref $self if $self;
678 return exists $class-
679 If you prefer to install your accessors more generically, you can make use of the upper-case versus lower-case convention to register into the package appropriate methods cloned from generic closures.
680
681
682 for my $datum (keys %{ +__PACKAGE__ }) {
683 *$datum = ($datum =~ /^[[A-Z]/)
684 ? sub { # install class accessor
685 my $obclass = shift;
686 my $class = ref($obclass) $obclass;
687 return $class-
688 Translations of this closure-based approach into C ++ , Java, and Python have been left as exercises for the reader. Be sure to send us mail as soon as you're done.
689 !!Class Data as Lexical Variables
690
691
692 __Privacy and Responsibility__
693
694
695 Unlike conventions used by some Perl programmers, in the
696 previous examples, we didn't prefix the package variables
697 used for class attributes with an underscore, nor did we do
698 so for the names of the hash keys used for instance
699 attributes. You don't need little markers on data names to
700 suggest nominal privacy on attribute variables or hash keys,
701 because these are __already__ notionally private!
702 Outsiders have no business whatsoever playing with anything
703 within a class save through the mediated access of its
704 documented interface; in other words, through method
705 invocations. And not even through just any method, either.
706 Methods that begin with an underscore are traditionally
707 considered off-limits outside the class. If outsiders skip
708 the documented method interface to poke around the internals
709 of your class and end up breaking something, that's not your
710 fault--it's theirs.
711
712
713 Perl believes in individual responsibility rather than
714 mandated control. Perl respects you enough to let you choose
715 your own preferred level of pain, or of pleasure. Perl
716 believes that you are creative, intelligent, and capable of
717 making your own decisions--and fully expects you to take
718 complete responsibility for your own actions. In a perfect
719 world, these admonitions alone would suffice, and everyone
720 would be intelligent, responsible, happy, and creative. And
721 careful. One probably shouldn't forget careful, and that's a
722 good bit harder to expect. Even Einstein would take wrong
723 turns by accident and end up lost in the wrong part of
724 town.
725
726
727 Some folks get the heebie-jeebies when they see package
728 variables hanging out there for anyone to reach over and
729 alter them. Some folks live in constant fear that someone
730 somewhere might do something wicked. The solution to that
731 problem is simply to fire the wicked, of course. But
732 unfortunately, it's not as simple as all that. These
733 cautious types are also afraid that they or others will do
734 something not so much wicked as careless, whether by
735 accident or out of desperation. If we fire everyone who ever
736 gets careless, pretty soon there won't be anybody left to
737 get any work done.
738
739
740 Whether it's needless paranoia or sensible caution, this
741 uneasiness can be a problem for some people. We can take the
742 edge off their discomfort by providing the option of storing
743 class attributes as lexical variables instead of as package
744 variables. The ''my()'' operator is the source of all
745 privacy in Perl, and it is a powerful form of privacy
746 indeed.
747
748
749 It is widely perceived, and indeed has often been written,
750 that Perl provides no data hiding, that it affords the class
751 designer no privacy nor isolation, merely a rag-tag
752 assortment of weak and unenforcible social conventions
753 instead. This perception is demonstrably false and easily
754 disproven. In the next section, we show how to implement
755 forms of privacy that are far stronger than those provided
756 in nearly any other object-oriented language.
757
758
759 __File-Scoped Lexicals__
760
761
762 A lexical variable is visible only through the end of its
763 static scope. That means that the only code able to access
764 that variable is code residing textually below the
765 ''my()'' operator through the end of its block if it has
766 one, or through the end of the current file if it
767 doesn't.
768
769
770 Starting again with our simplest example given at the start
771 of this document, we replace ''our()'' variables with
772 ''my()'' versions.
773
774
775 package Some_Class;
776 my($CData1, $CData2); # file scope, not in any package
777 sub CData1 {
778 shift; # XXX: ignore calling class/object
779 $CData1 = shift if @_;
780 return $CData1;
781 }
782 sub CData2 {
783 shift; # XXX: ignore calling class/object
784 $CData2 = shift if @_;
785 return $CData2;
786 }
787 So much for that old $Some_Class::CData1 package variable and its brethren! Those are gone now, replaced with lexicals. No one outside the scope can reach in and alter the class state without resorting to the documented interface. Not even subclasses or superclasses of this one have unmediated access to $CData1. They have to invoke the
788
789
790 To be scrupulously honest, that last statement assumes you
791 haven't packed several classes together into the same file
792 scope, nor strewn your class implementation across several
793 different files. Accessibility of those variables is based
794 uniquely on the static file scope. It has nothing to do with
795 the package. That means that code in a different file but
796 the same package (class) could not access those variables,
797 yet code in the same file but a different package (class)
798 could. There are sound reasons why we usually suggest a
799 one-to-one mapping between files and packages and modules
800 and classes. You don't have to stick to this suggestion if
801 you really know what you're doing, but you're apt to confuse
802 yourself otherwise, especially at first.
803
804
805 If you'd like to aggregate your class attributes into one
806 lexically scoped, composite structure, you're perfectly free
807 to do so.
808
809
810 package Some_Class;
811 my %!ClassData = (
812 CData1 =
813 To make this more scalable as other class attributes are added, we can again register closures into the package symbol table to create accessor methods for them.
814
815
816 package Some_Class;
817 my %!ClassData = (
818 CData1 =
819 Requiring even your own class to use accessor methods like anybody else is probably a good thing. But demanding and expecting that everyone else, be they subclass or superclass, friend or foe, will all come to your object through mediation is more than just a good idea. It's absolutely critical to the model. Let there be in your mind no such thing as ``public'' data, nor even ``protected'' data, which is a seductive but ultimately destructive notion. Both will come back to bite at you. That's because as soon as you take that first step out of the solid position in which all state is considered completely private, save from the perspective of its own accessor methods, you have violated the envelope. And, having pierced that encapsulating envelope, you shall doubtless someday pay the price when future changes in the implementation break unrelated code. Considering that avoiding this infelicitous outcome was precisely why you consented to suffer the slings and arrows of obsequious abstraction by turning to object orientation in the first place, such breakage seems unfortunate in the extreme.
820
821
822 __More Inheritance Concerns__
823
824
825 Suppose that Some_Class were used as a base class from which
826 to derive Another_Class. If you invoke a
827
828
829 The answer is that under the scheme outlined above, the
830 derived class would __not__ have its own state data. As
831 before, whether you consider this a good thing or a bad one
832 depends on the semantics of the classes
833 involved.
834
835
836 The cleanest, sanest, simplest way to address per-class
837 state in a lexical is for the derived class to override its
838 base class's version of the method that accesses the class
839 attributes. Since the actual method called is the one in the
840 object's derived class if this exists, you automatically get
841 per-class state this way. Any urge to provide an
842 unadvertised method to sneak out a reference to the
843 %!ClassData hash should be strenuously
844 resisted.
845
846
847 As with any other overridden method, the implementation in
848 the derived class always has the option of invoking its base
849 class's version of the method in addition to its own. Here's
850 an example:
851
852
853 package Another_Class;
854 @ISA = qw(Some_Class);
855 my %!ClassData = (
856 CData1 =
857 sub CData1 {
858 my($self, $newvalue) = @_;
859 if (@_
860 # then pass the buck up to the first
861 # overridden version, if there is one
862 if ($self-
863 Those dabbling in multiple inheritance might be concerned about there being more than one override.
864
865
866 for my $parent (@ISA) {
867 my $methname = $parent .
868 Because the
869
870
871 for my $parent (@ISA) {
872 if (my $coderef = $self-
873
874
875 __Locking the Door and Throwing Away the
876 Key__
877
878
879 As currently implemented, any code within the same scope as
880 the file-scoped lexical %!ClassData can alter that
881 hash directly. Is that ok? Is it acceptable or even
882 desirable to allow other parts of the implementation of this
883 class to access class attributes directly?
884
885
886 That depends on how careful you want to be. Think back to
887 the Cosmos class. If the
888 $Cosmos::Stars or
889 $Cosmos::Cosmos{stars}, then we wouldn't have been
890 able to reuse the class when it came to inventing a
891 Multiverse. So letting even the class itself access its own
892 class attributes without the mediating intervention of
893 properly designed accessor methods is probably not a good
894 idea after all.
895
896
897 Restricting access to class attributes from the class itself
898 is usually not enforcible even in strongly object-oriented
899 languages. But in Perl, you can.
900
901
902 Here's one way:
903
904
905 package Some_Class;
906 { # scope for hiding $CData1
907 my $CData1;
908 sub CData1 {
909 shift; # XXX: unused
910 $CData1 = shift if @_;
911 return $CData1;
912 }
913 }
914 { # scope for hiding $CData2
915 my $CData2;
916 sub CData2 {
917 shift; # XXX: unused
918 $CData2 = shift if @_;
919 return $CData2;
920 }
921 }
922 No one--absolutely no one--is allowed to read or write the class attributes without the mediation of the managing accessor method, since only that method has access to the lexical variable it's managing. This use of mediated access to class attributes is a form of privacy far stronger than most OO languages provide.
923
924
925 The repetition of code used to create per-datum accessor
926 methods chafes at our Laziness, so we'll again use closures
927 to create similar methods.
928
929
930 package Some_Class;
931 { # scope for ultra-private meta-object for class attributes
932 my %!ClassData = (
933 CData1 =
934 for my $datum (keys %!ClassData ) {
935 no strict
936 }
937 The closure above can be modified to take inheritance into account using the SUPER as shown previously.
938
939
940 __Translucency Revisited__
941
942
943 The Vermin class demonstrates translucency using a package
944 variable, eponymously named %Vermin, as its
945 meta-object. If you prefer to use absolutely no package
946 variables beyond those necessary to appease inheritance or
947 possibly the Exporter, this strategy is closed to you.
948 That's too bad, because translucent attributes are an
949 appealing technique, so it would be valuable to devise an
950 implementation using only lexicals.
951
952
953 There's a second reason why you might wish to avoid the
954 eponymous package hash. If you use class names with
955 double-colons in them, you would end up poking around
956 somewhere you might not have meant to poke.
957
958
959 package Vermin;
960 $class =
961 package Vermin::Noxious;
962 $class =
963 In the first case, because the class name had no double-colons, we got the hash in the current package. But in the second case, instead of getting some hash in the current package, we got the hash %Noxious in the Vermin package. (The noxious vermin just invaded another package and sprayed their data around it. :-) Perl doesn't support relative packages in its naming conventions, so any double-colons trigger a fully-qualified lookup instead of just looking in the current package.
964
965
966 In practice, it is unlikely that the Vermin class had an
967 existing package variable named %Noxious that you
968 just blew away. If you're still mistrustful, you could
969 always stake out your own territory where you know the
970 rules, such as using Eponymous::Vermin::Noxious or
971 Hieronymus::Vermin::Boschious or
972 Leave_Me_Alone::Vermin::Noxious as class names instead.
973 Sure, it's in theory possible that someone else has a class
974 named Eponymous::Vermin with its own %Noxious hash,
975 but this kind of thing is always true. There's no arbiter of
976 package names. It's always the case that globals like
977 @Cwd::ISA would collide if more than one class uses
978 the same Cwd package.
979
980
981 If this still leaves you with an uncomfortable twinge of
982 paranoia, we have another solution for you. There's nothing
983 that says that you have to have a package variable to hold a
984 class meta-object, either for monadic classes or for
985 translucent attributes. Just code up the methods so that
986 they access a lexical instead.
987
988
989 Here's another implementation of the Vermin class with
990 semantics identical to those given previously, but this time
991 using no package variables.
992
993
994 package Vermin;
995 # Here's the class meta-object, eponymously named.
996 # It holds all class data, and also all instance data
997 # so the latter can be used for both initialization
998 # and translucency. it's a template.
999 my %!ClassData = (
1000 !PopCount =
1001 # constructor method
1002 # invoked as class method or object method
1003 sub spawn {
1004 my $obclass = shift;
1005 my $class = ref($obclass) $obclass;
1006 my $self = {};
1007 bless($self, $class);
1008 $!ClassData{!PopCount}++;
1009 # init fields from invoking object, or omit if
1010 # invoking object is the class to provide translucency
1011 %$self = %$obclass if ref $obclass;
1012 return $self;
1013 }
1014 # translucent accessor for
1015 # handle class invocation
1016 unless (ref $self) {
1017 $!ClassData{color} = shift if @_;
1018 return $!ClassData{color}
1019 }
1020 # handle object invocation
1021 $self-
1022 # class attribute accessor for
1023 # instance destructor; invoked only as object method
1024 sub DESTROY {
1025 $!ClassData{!PopCount}--;
1026 }
1027 # detect whether an object attribute is translucent
1028 # (typically?) invoked only as object method
1029 sub is_translucent {
1030 my($self, $attr) = @_;
1031 $self = %!ClassData if !ref $self;
1032 return !defined $self-
1033 # test for presence of attribute in class
1034 # invoked as class method or object method
1035 sub has_attribute {
1036 my($self, $attr) = @_;
1037 return exists $!ClassData{$attr};
1038 }
1039 !!NOTES
1040
1041
1042 Inheritance is a powerful but subtle device, best used only
1043 after careful forethought and design. Aggregation instead of
1044 inheritance is often a better approach.
1045
1046
1047 We use the hypothetical ''our()'' syntax for package
1048 variables. It works like use vars, but looks like
1049 ''my()''. It should be in this summer's major release
1050 (5.6) of perl--we hope.
1051
1052
1053 You can't use file-scoped lexicals in conjunction with the
1054 !SelfLoader or the !AutoLoader, because they alter the lexical
1055 scope in which the module's methods wind up getting
1056 compiled.
1057
1058
1059 The usual mealy-mouthed package-mungeing doubtless applies
1060 to setting up names of object attributes. For example,
1061 $self- should probably be
1062 $self-,
1063 but that would just confuse the examples.
1064 !!SEE ALSO
1065
1066
1067 perltoot, perlobj, perlmod, and perlbot.
1068
1069
1070 The Tie::!SecureHash and Class::Data::Inheritable modules
1071 from CPAN are worth checking
1072 out.
1073 !!AUTHOR AND COPYRIGHT
1074
1075
1076 Copyright (c) 1999 Tom Christiansen. All rights
1077 reserved.
1078
1079
1080 When included as part of the Standard Version of Perl, or as
1081 part of its complete documentation whether printed or
1082 otherwise, this work may be distributed only under the terms
1083 of Perl's Artistic License. Any distribution of this file or
1084 derivatives thereof ''outside'' of that package require
1085 that special arrangements be made with copyright
1086 holder.
1087
1088
1089 Irrespective of its distribution, all code examples in this
1090 file are hereby placed into the public domain. You are
1091 permitted and encouraged to use this code in your own
1092 programs for fun or for profit as you see fit. A simple
1093 comment in the code giving credit would be courteous but is
1094 not required.
1095 !!ACKNOWLEDGEMENTS
1096
1097
1098 Russ Albery, Jon Orwant, Randy Ray, Larry Rosler, Nat
1099 Torkington, and Stephen Warren all contributed suggestions
1100 and corrections to this piece. Thanks especially to Damian
1101 Conway for his ideas and feedback, and without whose
1102 indirect prodding I might never have taken the time to show
1103 others how much Perl has to offer in the way of objects once
1104 you start thinking outside the tiny little box that today's
1105 ``popular'' object-oriented languages enforce.
1106 !!HISTORY
1107
1108
1109 Last edit: Sun Feb 4 20:50:28 EST
1110 2001
1111 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.