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