Commit | Line | Data |
---|---|---|
920dae64 AT |
1 | =head1 NAME |
2 | X<object> X<OOP> | |
3 | ||
4 | perlobj - Perl objects | |
5 | ||
6 | =head1 DESCRIPTION | |
7 | ||
8 | First you need to understand what references are in Perl. | |
9 | See L<perlref> for that. Second, if you still find the following | |
10 | reference work too complicated, a tutorial on object-oriented programming | |
11 | in Perl can be found in L<perltoot> and L<perltooc>. | |
12 | ||
13 | If you're still with us, then | |
14 | here are three very simple definitions that you should find reassuring. | |
15 | ||
16 | =over 4 | |
17 | ||
18 | =item 1. | |
19 | ||
20 | An object is simply a reference that happens to know which class it | |
21 | belongs to. | |
22 | ||
23 | =item 2. | |
24 | ||
25 | A class is simply a package that happens to provide methods to deal | |
26 | with object references. | |
27 | ||
28 | =item 3. | |
29 | ||
30 | A method is simply a subroutine that expects an object reference (or | |
31 | a package name, for class methods) as the first argument. | |
32 | ||
33 | =back | |
34 | ||
35 | We'll cover these points now in more depth. | |
36 | ||
37 | =head2 An Object is Simply a Reference | |
38 | X<object> X<bless> X<constructor> X<new> | |
39 | ||
40 | Unlike say C++, Perl doesn't provide any special syntax for | |
41 | constructors. A constructor is merely a subroutine that returns a | |
42 | reference to something "blessed" into a class, generally the | |
43 | class that the subroutine is defined in. Here is a typical | |
44 | constructor: | |
45 | ||
46 | package Critter; | |
47 | sub new { bless {} } | |
48 | ||
49 | That word C<new> isn't special. You could have written | |
50 | a construct this way, too: | |
51 | ||
52 | package Critter; | |
53 | sub spawn { bless {} } | |
54 | ||
55 | This might even be preferable, because the C++ programmers won't | |
56 | be tricked into thinking that C<new> works in Perl as it does in C++. | |
57 | It doesn't. We recommend that you name your constructors whatever | |
58 | makes sense in the context of the problem you're solving. For example, | |
59 | constructors in the Tk extension to Perl are named after the widgets | |
60 | they create. | |
61 | ||
62 | One thing that's different about Perl constructors compared with those in | |
63 | C++ is that in Perl, they have to allocate their own memory. (The other | |
64 | things is that they don't automatically call overridden base-class | |
65 | constructors.) The C<{}> allocates an anonymous hash containing no | |
66 | key/value pairs, and returns it The bless() takes that reference and | |
67 | tells the object it references that it's now a Critter, and returns | |
68 | the reference. This is for convenience, because the referenced object | |
69 | itself knows that it has been blessed, and the reference to it could | |
70 | have been returned directly, like this: | |
71 | ||
72 | sub new { | |
73 | my $self = {}; | |
74 | bless $self; | |
75 | return $self; | |
76 | } | |
77 | ||
78 | You often see such a thing in more complicated constructors | |
79 | that wish to call methods in the class as part of the construction: | |
80 | ||
81 | sub new { | |
82 | my $self = {}; | |
83 | bless $self; | |
84 | $self->initialize(); | |
85 | return $self; | |
86 | } | |
87 | ||
88 | If you care about inheritance (and you should; see | |
89 | L<perlmodlib/"Modules: Creation, Use, and Abuse">), | |
90 | then you want to use the two-arg form of bless | |
91 | so that your constructors may be inherited: | |
92 | ||
93 | sub new { | |
94 | my $class = shift; | |
95 | my $self = {}; | |
96 | bless $self, $class; | |
97 | $self->initialize(); | |
98 | return $self; | |
99 | } | |
100 | ||
101 | Or if you expect people to call not just C<< CLASS->new() >> but also | |
102 | C<< $obj->new() >>, then use something like the following. (Note that using | |
103 | this to call new() on an instance does not automatically perform any | |
104 | copying. If you want a shallow or deep copy of an object, you'll have to | |
105 | specifically allow for that.) The initialize() method used will be of | |
106 | whatever $class we blessed the object into: | |
107 | ||
108 | sub new { | |
109 | my $this = shift; | |
110 | my $class = ref($this) || $this; | |
111 | my $self = {}; | |
112 | bless $self, $class; | |
113 | $self->initialize(); | |
114 | return $self; | |
115 | } | |
116 | ||
117 | Within the class package, the methods will typically deal with the | |
118 | reference as an ordinary reference. Outside the class package, | |
119 | the reference is generally treated as an opaque value that may | |
120 | be accessed only through the class's methods. | |
121 | ||
122 | Although a constructor can in theory re-bless a referenced object | |
123 | currently belonging to another class, this is almost certainly going | |
124 | to get you into trouble. The new class is responsible for all | |
125 | cleanup later. The previous blessing is forgotten, as an object | |
126 | may belong to only one class at a time. (Although of course it's | |
127 | free to inherit methods from many classes.) If you find yourself | |
128 | having to do this, the parent class is probably misbehaving, though. | |
129 | ||
130 | A clarification: Perl objects are blessed. References are not. Objects | |
131 | know which package they belong to. References do not. The bless() | |
132 | function uses the reference to find the object. Consider | |
133 | the following example: | |
134 | ||
135 | $a = {}; | |
136 | $b = $a; | |
137 | bless $a, BLAH; | |
138 | print "\$b is a ", ref($b), "\n"; | |
139 | ||
140 | This reports $b as being a BLAH, so obviously bless() | |
141 | operated on the object and not on the reference. | |
142 | ||
143 | =head2 A Class is Simply a Package | |
144 | X<class> X<package> X<@ISA> X<inheritance> | |
145 | ||
146 | Unlike say C++, Perl doesn't provide any special syntax for class | |
147 | definitions. You use a package as a class by putting method | |
148 | definitions into the class. | |
149 | ||
150 | There is a special array within each package called @ISA, which says | |
151 | where else to look for a method if you can't find it in the current | |
152 | package. This is how Perl implements inheritance. Each element of the | |
153 | @ISA array is just the name of another package that happens to be a | |
154 | class package. The classes are searched (depth first) for missing | |
155 | methods in the order that they occur in @ISA. The classes accessible | |
156 | through @ISA are known as base classes of the current class. | |
157 | ||
158 | All classes implicitly inherit from class C<UNIVERSAL> as their | |
159 | last base class. Several commonly used methods are automatically | |
160 | supplied in the UNIVERSAL class; see L<"Default UNIVERSAL methods"> for | |
161 | more details. | |
162 | X<UNIVERSAL> X<base class> X<class, base> | |
163 | ||
164 | If a missing method is found in a base class, it is cached | |
165 | in the current class for efficiency. Changing @ISA or defining new | |
166 | subroutines invalidates the cache and causes Perl to do the lookup again. | |
167 | ||
168 | If neither the current class, its named base classes, nor the UNIVERSAL | |
169 | class contains the requested method, these three places are searched | |
170 | all over again, this time looking for a method named AUTOLOAD(). If an | |
171 | AUTOLOAD is found, this method is called on behalf of the missing method, | |
172 | setting the package global $AUTOLOAD to be the fully qualified name of | |
173 | the method that was intended to be called. | |
174 | X<AUTOLOAD> | |
175 | ||
176 | If none of that works, Perl finally gives up and complains. | |
177 | ||
178 | If you want to stop the AUTOLOAD inheritance say simply | |
179 | X<AUTOLOAD> | |
180 | ||
181 | sub AUTOLOAD; | |
182 | ||
183 | and the call will die using the name of the sub being called. | |
184 | ||
185 | Perl classes do method inheritance only. Data inheritance is left up | |
186 | to the class itself. By and large, this is not a problem in Perl, | |
187 | because most classes model the attributes of their object using an | |
188 | anonymous hash, which serves as its own little namespace to be carved up | |
189 | by the various classes that might want to do something with the object. | |
190 | The only problem with this is that you can't sure that you aren't using | |
191 | a piece of the hash that isn't already used. A reasonable workaround | |
192 | is to prepend your fieldname in the hash with the package name. | |
193 | X<inheritance, method> X<inheritance, data> | |
194 | ||
195 | sub bump { | |
196 | my $self = shift; | |
197 | $self->{ __PACKAGE__ . ".count"}++; | |
198 | } | |
199 | ||
200 | =head2 A Method is Simply a Subroutine | |
201 | X<method> | |
202 | ||
203 | Unlike say C++, Perl doesn't provide any special syntax for method | |
204 | definition. (It does provide a little syntax for method invocation | |
205 | though. More on that later.) A method expects its first argument | |
206 | to be the object (reference) or package (string) it is being invoked | |
207 | on. There are two ways of calling methods, which we'll call class | |
208 | methods and instance methods. | |
209 | ||
210 | A class method expects a class name as the first argument. It | |
211 | provides functionality for the class as a whole, not for any | |
212 | individual object belonging to the class. Constructors are often | |
213 | class methods, but see L<perltoot> and L<perltooc> for alternatives. | |
214 | Many class methods simply ignore their first argument, because they | |
215 | already know what package they're in and don't care what package | |
216 | they were invoked via. (These aren't necessarily the same, because | |
217 | class methods follow the inheritance tree just like ordinary instance | |
218 | methods.) Another typical use for class methods is to look up an | |
219 | object by name: | |
220 | ||
221 | sub find { | |
222 | my ($class, $name) = @_; | |
223 | $objtable{$name}; | |
224 | } | |
225 | ||
226 | An instance method expects an object reference as its first argument. | |
227 | Typically it shifts the first argument into a "self" or "this" variable, | |
228 | and then uses that as an ordinary reference. | |
229 | ||
230 | sub display { | |
231 | my $self = shift; | |
232 | my @keys = @_ ? @_ : sort keys %$self; | |
233 | foreach $key (@keys) { | |
234 | print "\t$key => $self->{$key}\n"; | |
235 | } | |
236 | } | |
237 | ||
238 | =head2 Method Invocation | |
239 | X<invocation> X<method> X<arrow> X<< -> >> | |
240 | ||
241 | For various historical and other reasons, Perl offers two equivalent | |
242 | ways to write a method call. The simpler and more common way is to use | |
243 | the arrow notation: | |
244 | ||
245 | my $fred = Critter->find("Fred"); | |
246 | $fred->display("Height", "Weight"); | |
247 | ||
248 | You should already be familiar with the use of the C<< -> >> operator with | |
249 | references. In fact, since C<$fred> above is a reference to an object, | |
250 | you could think of the method call as just another form of | |
251 | dereferencing. | |
252 | ||
253 | Whatever is on the left side of the arrow, whether a reference or a | |
254 | class name, is passed to the method subroutine as its first argument. | |
255 | So the above code is mostly equivalent to: | |
256 | ||
257 | my $fred = Critter::find("Critter", "Fred"); | |
258 | Critter::display($fred, "Height", "Weight"); | |
259 | ||
260 | How does Perl know which package the subroutine is in? By looking at | |
261 | the left side of the arrow, which must be either a package name or a | |
262 | reference to an object, i.e. something that has been blessed to a | |
263 | package. Either way, that's the package where Perl starts looking. If | |
264 | that package has no subroutine with that name, Perl starts looking for | |
265 | it in any base classes of that package, and so on. | |
266 | ||
267 | If you need to, you I<can> force Perl to start looking in some other package: | |
268 | ||
269 | my $barney = MyCritter->Critter::find("Barney"); | |
270 | $barney->Critter::display("Height", "Weight"); | |
271 | ||
272 | Here C<MyCritter> is presumably a subclass of C<Critter> that defines | |
273 | its own versions of find() and display(). We haven't specified what | |
274 | those methods do, but that doesn't matter above since we've forced Perl | |
275 | to start looking for the subroutines in C<Critter>. | |
276 | ||
277 | As a special case of the above, you may use the C<SUPER> pseudo-class to | |
278 | tell Perl to start looking for the method in the packages named in the | |
279 | current class's C<@ISA> list. | |
280 | X<SUPER> | |
281 | ||
282 | package MyCritter; | |
283 | use base 'Critter'; # sets @MyCritter::ISA = ('Critter'); | |
284 | ||
285 | sub display { | |
286 | my ($self, @args) = @_; | |
287 | $self->SUPER::display("Name", @args); | |
288 | } | |
289 | ||
290 | It is important to note that C<SUPER> refers to the superclass(es) of the | |
291 | I<current package> and not to the superclass(es) of the object. Also, the | |
292 | C<SUPER> pseudo-class can only currently be used as a modifier to a method | |
293 | name, but not in any of the other ways that class names are normally used, | |
294 | eg: | |
295 | X<SUPER> | |
296 | ||
297 | something->SUPER::method(...); # OK | |
298 | SUPER::method(...); # WRONG | |
299 | SUPER->method(...); # WRONG | |
300 | ||
301 | Instead of a class name or an object reference, you can also use any | |
302 | expression that returns either of those on the left side of the arrow. | |
303 | So the following statement is valid: | |
304 | ||
305 | Critter->find("Fred")->display("Height", "Weight"); | |
306 | ||
307 | and so is the following: | |
308 | ||
309 | my $fred = (reverse "rettirC")->find(reverse "derF"); | |
310 | ||
311 | The right side of the arrow typically is the method name, but a simple | |
312 | scalar variable containing either the method name or a subroutine | |
313 | reference can also be used. | |
314 | ||
315 | =head2 Indirect Object Syntax | |
316 | X<indirect object syntax> X<invocation, indirect> X<indirect> | |
317 | ||
318 | The other way to invoke a method is by using the so-called "indirect | |
319 | object" notation. This syntax was available in Perl 4 long before | |
320 | objects were introduced, and is still used with filehandles like this: | |
321 | ||
322 | print STDERR "help!!!\n"; | |
323 | ||
324 | The same syntax can be used to call either object or class methods. | |
325 | ||
326 | my $fred = find Critter "Fred"; | |
327 | display $fred "Height", "Weight"; | |
328 | ||
329 | Notice that there is no comma between the object or class name and the | |
330 | parameters. This is how Perl can tell you want an indirect method call | |
331 | instead of an ordinary subroutine call. | |
332 | ||
333 | But what if there are no arguments? In that case, Perl must guess what | |
334 | you want. Even worse, it must make that guess I<at compile time>. | |
335 | Usually Perl gets it right, but when it doesn't you get a function | |
336 | call compiled as a method, or vice versa. This can introduce subtle bugs | |
337 | that are hard to detect. | |
338 | ||
339 | For example, a call to a method C<new> in indirect notation -- as C++ | |
340 | programmers are wont to make -- can be miscompiled into a subroutine | |
341 | call if there's already a C<new> function in scope. You'd end up | |
342 | calling the current package's C<new> as a subroutine, rather than the | |
343 | desired class's method. The compiler tries to cheat by remembering | |
344 | bareword C<require>s, but the grief when it messes up just isn't worth the | |
345 | years of debugging it will take you to track down such subtle bugs. | |
346 | ||
347 | There is another problem with this syntax: the indirect object is | |
348 | limited to a name, a scalar variable, or a block, because it would have | |
349 | to do too much lookahead otherwise, just like any other postfix | |
350 | dereference in the language. (These are the same quirky rules as are | |
351 | used for the filehandle slot in functions like C<print> and C<printf>.) | |
352 | This can lead to horribly confusing precedence problems, as in these | |
353 | next two lines: | |
354 | ||
355 | move $obj->{FIELD}; # probably wrong! | |
356 | move $ary[$i]; # probably wrong! | |
357 | ||
358 | Those actually parse as the very surprising: | |
359 | ||
360 | $obj->move->{FIELD}; # Well, lookee here | |
361 | $ary->move([$i]); # Didn't expect this one, eh? | |
362 | ||
363 | Rather than what you might have expected: | |
364 | ||
365 | $obj->{FIELD}->move(); # You should be so lucky. | |
366 | $ary[$i]->move; # Yeah, sure. | |
367 | ||
368 | To get the correct behavior with indirect object syntax, you would have | |
369 | to use a block around the indirect object: | |
370 | ||
371 | move {$obj->{FIELD}}; | |
372 | move {$ary[$i]}; | |
373 | ||
374 | Even then, you still have the same potential problem if there happens to | |
375 | be a function named C<move> in the current package. B<The C<< -> >> | |
376 | notation suffers from neither of these disturbing ambiguities, so we | |
377 | recommend you use it exclusively.> However, you may still end up having | |
378 | to read code using the indirect object notation, so it's important to be | |
379 | familiar with it. | |
380 | ||
381 | =head2 Default UNIVERSAL methods | |
382 | X<UNIVERSAL> | |
383 | ||
384 | The C<UNIVERSAL> package automatically contains the following methods that | |
385 | are inherited by all other classes: | |
386 | ||
387 | =over 4 | |
388 | ||
389 | =item isa(CLASS) | |
390 | X<isa> | |
391 | ||
392 | C<isa> returns I<true> if its object is blessed into a subclass of C<CLASS> | |
393 | ||
394 | You can also call C<UNIVERSAL::isa> as a subroutine with two arguments. Of | |
395 | course, this will do the wrong thing if someone has overridden C<isa> in a | |
396 | class, so don't do it. | |
397 | ||
398 | If you need to determine whether you've received a valid invocant, use the | |
399 | C<blessed> function from L<Scalar::Util>: | |
400 | X<invocant> X<blessed> | |
401 | ||
402 | if (blessed($ref) && $ref->isa( 'Some::Class')) { | |
403 | # ... | |
404 | } | |
405 | ||
406 | C<blessed> returns the name of the package the argument has been | |
407 | blessed into, or C<undef>. | |
408 | ||
409 | =item can(METHOD) | |
410 | X<can> | |
411 | ||
412 | C<can> checks to see if its object has a method called C<METHOD>, | |
413 | if it does then a reference to the sub is returned, if it does not then | |
414 | I<undef> is returned. | |
415 | ||
416 | C<UNIVERSAL::can> can also be called as a subroutine with two arguments. It'll | |
417 | always return I<undef> if its first argument isn't an object or a class name. | |
418 | The same caveats for calling C<UNIVERSAL::isa> directly apply here, too. | |
419 | ||
420 | =item VERSION( [NEED] ) | |
421 | X<VERSION> | |
422 | ||
423 | C<VERSION> returns the version number of the class (package). If the | |
424 | NEED argument is given then it will check that the current version (as | |
425 | defined by the $VERSION variable in the given package) not less than | |
426 | NEED; it will die if this is not the case. This method is normally | |
427 | called as a class method. This method is called automatically by the | |
428 | C<VERSION> form of C<use>. | |
429 | ||
430 | use A 1.2 qw(some imported subs); | |
431 | # implies: | |
432 | A->VERSION(1.2); | |
433 | ||
434 | =back | |
435 | ||
436 | B<NOTE:> C<can> directly uses Perl's internal code for method lookup, and | |
437 | C<isa> uses a very similar method and cache-ing strategy. This may cause | |
438 | strange effects if the Perl code dynamically changes @ISA in any package. | |
439 | ||
440 | You may add other methods to the UNIVERSAL class via Perl or XS code. | |
441 | You do not need to C<use UNIVERSAL> to make these methods | |
442 | available to your program (and you should not do so). | |
443 | ||
444 | =head2 Destructors | |
445 | X<destructor> X<DESTROY> | |
446 | ||
447 | When the last reference to an object goes away, the object is | |
448 | automatically destroyed. (This may even be after you exit, if you've | |
449 | stored references in global variables.) If you want to capture control | |
450 | just before the object is freed, you may define a DESTROY method in | |
451 | your class. It will automatically be called at the appropriate moment, | |
452 | and you can do any extra cleanup you need to do. Perl passes a reference | |
453 | to the object under destruction as the first (and only) argument. Beware | |
454 | that the reference is a read-only value, and cannot be modified by | |
455 | manipulating C<$_[0]> within the destructor. The object itself (i.e. | |
456 | the thingy the reference points to, namely C<${$_[0]}>, C<@{$_[0]}>, | |
457 | C<%{$_[0]}> etc.) is not similarly constrained. | |
458 | ||
459 | Since DESTROY methods can be called at unpredictable times, it is | |
460 | important that you localise any global variables that the method may | |
461 | update. In particular, localise C<$@> if you use C<eval {}> and | |
462 | localise C<$?> if you use C<system> or backticks. | |
463 | ||
464 | If you arrange to re-bless the reference before the destructor returns, | |
465 | perl will again call the DESTROY method for the re-blessed object after | |
466 | the current one returns. This can be used for clean delegation of | |
467 | object destruction, or for ensuring that destructors in the base classes | |
468 | of your choosing get called. Explicitly calling DESTROY is also possible, | |
469 | but is usually never needed. | |
470 | ||
471 | Do not confuse the previous discussion with how objects I<CONTAINED> in the current | |
472 | one are destroyed. Such objects will be freed and destroyed automatically | |
473 | when the current object is freed, provided no other references to them exist | |
474 | elsewhere. | |
475 | ||
476 | =head2 Summary | |
477 | ||
478 | That's about all there is to it. Now you need just to go off and buy a | |
479 | book about object-oriented design methodology, and bang your forehead | |
480 | with it for the next six months or so. | |
481 | ||
482 | =head2 Two-Phased Garbage Collection | |
483 | X<garbage collection> X<GC> X<circular reference> | |
484 | X<reference, circular> X<DESTROY> X<destructor> | |
485 | ||
486 | For most purposes, Perl uses a fast and simple, reference-based | |
487 | garbage collection system. That means there's an extra | |
488 | dereference going on at some level, so if you haven't built | |
489 | your Perl executable using your C compiler's C<-O> flag, performance | |
490 | will suffer. If you I<have> built Perl with C<cc -O>, then this | |
491 | probably won't matter. | |
492 | ||
493 | A more serious concern is that unreachable memory with a non-zero | |
494 | reference count will not normally get freed. Therefore, this is a bad | |
495 | idea: | |
496 | ||
497 | { | |
498 | my $a; | |
499 | $a = \$a; | |
500 | } | |
501 | ||
502 | Even thought $a I<should> go away, it can't. When building recursive data | |
503 | structures, you'll have to break the self-reference yourself explicitly | |
504 | if you don't care to leak. For example, here's a self-referential | |
505 | node such as one might use in a sophisticated tree structure: | |
506 | ||
507 | sub new_node { | |
508 | my $class = shift; | |
509 | my $node = {}; | |
510 | $node->{LEFT} = $node->{RIGHT} = $node; | |
511 | $node->{DATA} = [ @_ ]; | |
512 | return bless $node => $class; | |
513 | } | |
514 | ||
515 | If you create nodes like that, they (currently) won't go away unless you | |
516 | break their self reference yourself. (In other words, this is not to be | |
517 | construed as a feature, and you shouldn't depend on it.) | |
518 | ||
519 | Almost. | |
520 | ||
521 | When an interpreter thread finally shuts down (usually when your program | |
522 | exits), then a rather costly but complete mark-and-sweep style of garbage | |
523 | collection is performed, and everything allocated by that thread gets | |
524 | destroyed. This is essential to support Perl as an embedded or a | |
525 | multithreadable language. For example, this program demonstrates Perl's | |
526 | two-phased garbage collection: | |
527 | ||
528 | #!/usr/bin/perl | |
529 | package Subtle; | |
530 | ||
531 | sub new { | |
532 | my $test; | |
533 | $test = \$test; | |
534 | warn "CREATING " . \$test; | |
535 | return bless \$test; | |
536 | } | |
537 | ||
538 | sub DESTROY { | |
539 | my $self = shift; | |
540 | warn "DESTROYING $self"; | |
541 | } | |
542 | ||
543 | package main; | |
544 | ||
545 | warn "starting program"; | |
546 | { | |
547 | my $a = Subtle->new; | |
548 | my $b = Subtle->new; | |
549 | $$a = 0; # break selfref | |
550 | warn "leaving block"; | |
551 | } | |
552 | ||
553 | warn "just exited block"; | |
554 | warn "time to die..."; | |
555 | exit; | |
556 | ||
557 | When run as F</foo/test>, the following output is produced: | |
558 | ||
559 | starting program at /foo/test line 18. | |
560 | CREATING SCALAR(0x8e5b8) at /foo/test line 7. | |
561 | CREATING SCALAR(0x8e57c) at /foo/test line 7. | |
562 | leaving block at /foo/test line 23. | |
563 | DESTROYING Subtle=SCALAR(0x8e5b8) at /foo/test line 13. | |
564 | just exited block at /foo/test line 26. | |
565 | time to die... at /foo/test line 27. | |
566 | DESTROYING Subtle=SCALAR(0x8e57c) during global destruction. | |
567 | ||
568 | Notice that "global destruction" bit there? That's the thread | |
569 | garbage collector reaching the unreachable. | |
570 | ||
571 | Objects are always destructed, even when regular refs aren't. Objects | |
572 | are destructed in a separate pass before ordinary refs just to | |
573 | prevent object destructors from using refs that have been themselves | |
574 | destructed. Plain refs are only garbage-collected if the destruct level | |
575 | is greater than 0. You can test the higher levels of global destruction | |
576 | by setting the PERL_DESTRUCT_LEVEL environment variable, presuming | |
577 | C<-DDEBUGGING> was enabled during perl build time. | |
578 | See L<perlhack/PERL_DESTRUCT_LEVEL> for more information. | |
579 | ||
580 | A more complete garbage collection strategy will be implemented | |
581 | at a future date. | |
582 | ||
583 | In the meantime, the best solution is to create a non-recursive container | |
584 | class that holds a pointer to the self-referential data structure. | |
585 | Define a DESTROY method for the containing object's class that manually | |
586 | breaks the circularities in the self-referential structure. | |
587 | ||
588 | =head1 SEE ALSO | |
589 | ||
590 | A kinder, gentler tutorial on object-oriented programming in Perl can | |
591 | be found in L<perltoot>, L<perlboot> and L<perltooc>. You should | |
592 | also check out L<perlbot> for other object tricks, traps, and tips, as | |
593 | well as L<perlmodlib> for some style guides on constructing both | |
594 | modules and classes. |