1HTML::Tree::AboutObjectUss(e3r)Contributed Perl DocumentHaTtMiLo:n:Tree::AboutObjects(3)
2
6 HTML::Tree::AboutObjects -- article: "User's View of Object-Oriented
7 Modules"
8
10 # This an article, not a module.
11
13 The following article by Sean M. Burke first appeared in The Perl
14 Journal #17 and is copyright 2000 The Perl Journal. It appears courtesy
15 of Jon Orwant and The Perl Journal. This document may be distributed
16 under the same terms as Perl itself.
17
19 -- Sean M. Burke
20 The first time that most Perl programmers run into object-oriented
22 programming when they need to use a module whose interface is object-
23 oriented. This is often a mystifying experience, since talk of
24 "methods" and "constructors" is unintelligible to programmers who
25 thought that functions and variables was all there was to worry about.
26 Articles and books that explain object-oriented programming (OOP), do
28 so in terms of how to program that way. That's understandable, and if
29 you learn to write object-oriented code of your own, you'd find it easy
30 to use object-oriented code that others write. But this approach is
31 the long way around for people whose immediate goal is just to use
32 existing object-oriented modules, but who don't yet want to know all
33 the gory details of having to write such modules for themselves.
34 This article is for those programmers -- programmers who want to know
36 about objects from the perspective of using object-oriented modules.
37 Modules and Their Functional Interfaces
39 Modules are the main way that Perl provides for bundling up code for
40 later use by yourself or others. As I'm sure you can't help noticing
41 from reading The Perl Journal, CPAN (the Comprehensive Perl Archive
42 Network) is the repository for modules (or groups of modules) that
43 others have written, to do anything from composing music to accessing
44 Web pages. A good deal of those modules even come with every
45 installation of Perl.
46 One module that you may have used before, and which is fairly typical
48 in its interface, is Text::Wrap. It comes with Perl, so you don't even
49 need to install it from CPAN. You use it in a program of yours, by
50 having your program code say early on:
51 use Text::Wrap;
53 and after that, you can access a function called "wrap", which inserts
55 line-breaks in text that you feed it, so that the text will be wrapped
56 to seventy-two (or however many) columns.
57 The way this "use Text::Wrap" business works is that the module
59 Text::Wrap exists as a file "Text/Wrap.pm" somewhere in one of your
60 library directories. That file contains Perl code...
61 Footnote: And mixed in with the Perl code, there's documentation,
63 which is what you read with "perldoc Text::Wrap". The perldoc
64 program simply ignores the code and formats the documentation text,
65 whereas "use Text::Wrap" loads and runs the code while ignoring the
66 documentation.
67 ...which, among other things, defines a function called
69 "Text::Wrap::wrap", and then "exports" that function, which means that
70 when you say "wrap" after having said "use Text::Wrap", you'll be
71 actually calling the "Text::Wrap::wrap" function. Some modules don't
72 export their functions, so you have to call them by their full name,
73 like "Text::Wrap::wrap(...parameters...)".
74 Regardless of whether the typical module exports the functions it
76 provides, a module is basically just a container for chunks of code
77 that do useful things. The way the module allows for you to interact
78 with it, is its interface. And when, like with Text::Wrap, its
79 interface consists of functions, the module is said to have a
80 functional interface.
81 Footnote: the term "function" (and therefore "functional") has
83 various senses. I'm using the term here in its broadest sense, to
84 refer to routines -- bits of code that are called by some name and
85 which take parameters and return some value.
86 Using modules with functional interfaces is straightforward -- instead
88 of defining your own "wrap" function with "sub wrap { ... }", you
89 entrust "use Text::Wrap" to do that for you, along with whatever other
90 functions its defines and exports, according to the module's
91 documentation. Without too much bother, you can even write your own
92 modules to contain your frequently used functions; I suggest having a
93 look at the "perlmod" man page for more leads on doing this.
94 Modules with Object-Oriented Interfaces
96 So suppose that one day you want to write a program that will automate
97 the process of "ftp"ing a bunch of files from one server down to your
98 local machine, and then off to another server.
99 A quick browse through search.cpan.org turns up the module "Net::FTP",
101 which you can download and install it using normal installation
102 instructions (unless your sysadmin has already installed it, as many
103 have).
104 Like Text::Wrap or any other module with a familiarly functional
106 interface, you start off using Net::FTP in your program by saying:
107 use Net::FTP;
109 However, that's where the similarity ends. The first hint of
111 difference is that the documentation for Net::FTP refers to it as a
112 class. A class is a kind of module, but one that has an object-
113 oriented interface.
114 Whereas modules like Text::Wrap provide bits of useful code as
116 functions, to be called like "function(...parameters...)" or like
117 "PackageName::function(...parameters...)", Net::FTP and other modules
118 with object-oriented interfaces provide methods. Methods are sort of
119 like functions in that they have a name and parameters; but methods
120 look different, and are different, because you have to call them with a
121 syntax that has a class name or an object as a special argument. I'll
122 explain the syntax for method calls, and then later explain what they
123 all mean.
124 Some methods are meant to be called as class methods, with the class
126 name (same as the module name) as a special argument. Class methods
127 look like this:
128 ClassName->methodname(parameter1, parameter2, ...)
130 ClassName->methodname() # if no parameters
131 ClassName->methodname # same as above
132 which you will sometimes see written:
134 methodname ClassName (parameter1, parameter2, ...)
136 methodname ClassName # if no parameters
137 Basically all class methods are for making new objects, and methods
139 that make objects are called "constructors" (and the process of making
140 them is called "constructing" or "instantiating"). Constructor methods
141 typically have the name "new", or something including "new"
142 ("new_from_file", etc.); but they can conceivably be named anything --
143 DBI's constructor method is named "connect", for example.
144 The object that a constructor method returns is typically captured in a
146 scalar variable:
147 $object = ClassName->new(param1, param2...);
149 Once you have an object (more later on exactly what that is), you can
151 use the other kind of method call syntax, the syntax for object method
152 calls. Calling object methods is just like class methods, except that
153 instead of the ClassName as the special argument, you use an expression
154 that yeilds an "object". Usually this is just a scalar variable that
155 you earlier captured the output of the constructor in. Object method
156 calls look like this:
157 $object->methodname(parameter1, parameter2, ...);
159 $object->methodname() # if no parameters
160 $object->methodname # same as above
161 which is occasionally written as:
163 methodname $object (parameter1, parameter2, ...)
165 methodname $object # if no parameters
166 Examples of method calls are:
168 my $session1 = Net::FTP->new("ftp.myhost.com");
170 # Calls a class method "new", from class Net::FTP,
171 # with the single parameter "ftp.myhost.com",
172 # and saves the return value (which is, as usual,
173 # an object), in $session1.
174 # Could also be written:
175 # new Net::FTP('ftp.myhost.com')
176 $session1->login("sburke","aoeuaoeu")
177 || die "failed to login!\n";
178 # calling the object method "login"
179 print "Dir:\n", $session1->dir(), "\n";
180 $session1->quit;
181 # same as $session1->quit()
182 print "Done\n";
183 exit;
184 Incidentally, I suggest always using the syntaxes with parentheses and
186 "->" in them,
187 Footnote: the character-pair "->" is supposed to look like an
189 arrow, not "negative greater-than"!
190 and avoiding the syntaxes that start out "methodname $object" or
192 "methodname ModuleName". When everything's going right, they all mean
193 the same thing as the "->" variants, but the syntax with "->" is more
194 visually distinct from function calls, as well as being immune to some
195 kinds of rare but puzzling ambiguities that can arise when you're
196 trying to call methods that have the same name as subroutines you've
197 defined.
198 But, syntactic alternatives aside, all this talk of constructing
200 objects and object methods begs the question -- what is an object?
201 There are several angles to this question that the rest of this article
202 will answer in turn: what can you do with objects? what's in an
203 object? what's an object value? and why do some modules use objects
204 at all?
205 What Can You Do with Objects?
207 You've seen that you can make objects, and call object methods with
208 them. But what are object methods for? The answer depends on the
209 class:
210 A Net::FTP object represents a session between your computer and an FTP
212 server. So the methods you call on a Net::FTP object are for doing
213 whatever you'd need to do across an FTP connection. You make the
214 session and log in:
215 my $session = Net::FTP->new('ftp.aol.com');
217 die "Couldn't connect!" unless defined $session;
218 # The class method call to "new" will return
219 # the new object if it goes OK, otherwise it
220 # will return undef.
221 $session->login('sburke', 'p@ssw3rD')
223 || die "Did I change my password again?";
224 # The object method "login" will give a true
225 # return value if actually logs in, otherwise
226 # it'll return false.
227 You can use the session object to change directory on that session:
229 $session->cwd("/home/sburke/public_html")
231 || die "Hey, that was REALLY supposed to work!";
232 # if the cwd fails, it'll return false
233 ...get files from the machine at the other end of the session...
235 foreach my $f ('log_report_ua.txt', 'log_report_dom.txt',
237 'log_report_browsers.txt')
238 {
239 $session->get($f) || warn "Getting $f failed!"
240 };
241 ...and plenty else, ending finally with closing the connection:
243 $session->quit();
245 In short, object methods are for doing things related to (or with)
247 whatever the object represents. For FTP sessions, it's about sending
248 commands to the server at the other end of the connection, and that's
249 about it -- there, methods are for doing something to the world outside
250 the object, and the objects is just something that specifies what bit
251 of the world (well, what FTP session) to act upon.
252 With most other classes, however, the object itself stores some kind of
254 information, and it typically makes no sense to do things with such an
255 object without considering the data that's in the object.
256 What's in an Object?
258 An object is (with rare exceptions) a data structure containing a bunch
259 of attributes, each of which has a value, as well as a name that you
260 use when you read or set the attribute's value. Some of the object's
261 attributes are private, meaning you'll never see them documented
262 because they're not for you to read or write; but most of the object's
263 documented attributes are at least readable, and usually writeable, by
264 you. Net::FTP objects are a bit thin on attributes, so we'll use
265 objects from the class Business::US_Amort for this example.
266 Business::US_Amort is a very simple class (available from CPAN) that I
267 wrote for making calculations to do with loans (specifically,
268 amortization, using US-style algorithms).
269 An object of the class Business::US_Amort represents a loan with
271 particular parameters, i.e., attributes. The most basic attributes of
272 a "loan object" are its interest rate, its principal (how much money
273 it's for), and it's term (how long it'll take to repay). You need to
274 set these attributes before anything else can be done with the object.
275 The way to get at those attributes for loan objects is just like the
276 way to get at attributes for any class's objects: through accessors.
277 An accessor is simply any method that accesses (whether reading or
278 writing, AKA getting or putting) some attribute in the given object.
279 Moreover, accessors are the only way that you can change an object's
280 attributes. (If a module's documentation wants you to know about any
281 other way, it'll tell you.)
282 Usually, for simplicity's sake, an accessor is named after the
284 attribute it reads or writes. With Business::US_Amort objects, the
285 accessors you need to use first are "principal", "interest_rate", and
286 "term". Then, with at least those attributes set, you can call the
287 "run" method to figure out several things about the loan. Then you can
288 call various accessors, like "total_paid_toward_interest", to read the
289 results:
290 use Business::US_Amort;
292 my $loan = Business::US_Amort->new;
293 # Set the necessary attributes:
294 $loan->principal(123654);
295 $loan->interest_rate(9.25);
296 $loan->term(20); # twenty years
297 # NOW we know enough to calculate:
299 $loan->run;
300 # And see what came of that:
302 print
303 "Total paid toward interest: A WHOPPING ",
304 $loan->total_paid_interest, "!!\n";
305 This illustrates a convention that's common with accessors: calling the
307 accessor with no arguments (as with $loan->total_paid_interest) usually
308 means to read the value of that attribute, but providing a value (as
309 with $loan->term(20)) means you want that attribute to be set to that
310 value. This stands to reason: why would you be providing a value, if
311 not to set the attribute to that value?
312 Although a loan's term, principal, and interest rates are all single
314 numeric values, an objects values can any kind of scalar, or an array,
315 or even a hash. Moreover, an attribute's value(s) can be objects
316 themselves. For example, consider MIDI files (as I wrote about in
317 TPJ#13): a MIDI file usually consists of several tracks. A MIDI file
318 is complex enough to merit being an object with attributes like its
319 overall tempo, the file-format variant it's in, and the list of
320 instrument tracks in the file. But tracks themselves are complex
321 enough to be objects too, with attributes like their track-type, a list
322 of MIDI commands if they're a MIDI track, or raw data if they're not.
323 So I ended up writing the MIDI modules so that the "tracks" attribute
324 of a MIDI::Opus object is an array of objects from the class
325 MIDI::Track. This may seem like a runaround -- you ask what's in one
326 object, and get another object, or several! But in this case, it
327 exactly reflects what the module is for -- MIDI files contain MIDI
328 tracks, which then contain data.
329 What is an Object Value?
331 When you call a constructor like Net::FTP->new(hostname), you get back
332 an object value, a value you can later use, in combination with a
333 method name, to call object methods.
334 Now, so far we've been pretending, in the above examples, that the
336 variables $session or $loan are the objects you're dealing with. This
337 idea is innocuous up to a point, but it's really a misconception that
338 will, at best, limit you in what you know how to do. The reality is
339 not that the variables $session or $query are objects; it's a little
340 more indirect -- they hold values that symbolize objects. The kind of
341 value that $session or $query hold is what I'm calling an object value.
342 To understand what kind of value this is, first think about the other
344 kinds of scalar values you know about: The first two scalar values you
345 probably ever ran into in Perl are numbers and strings, which you
346 learned (or just assumed) will usually turn into each other on demand;
347 that is, the three-character string "2.5" can become the quantity two
348 and a half, and vice versa. Then, especially if you started using
349 "perl -w" early on, you learned about the undefined value, which can
350 turn into 0 if you treat it as a number, or the empty-string if you
351 treat it as a string.
352 Footnote: You may also have been learning about references, in
354 which case you're ready to hear that object values are just a kind
355 of reference, except that they reflect the class that created thing
356 they point to, instead of merely being a plain old array reference,
357 hash reference, etc. If this makes makes sense to you, and you
358 want to know more about how objects are implemented in Perl, have a
359 look at the "perltoot" man page.
360 And now you're learning about object values. An object value is a
362 value that points to a data structure somewhere in memory, which is
363 where all the attributes for this object are stored. That data
364 structure as a whole belongs to a class (probably the one you named in
365 the constructor method, like ClassName->new), so that the object value
366 can be used as part of object method calls.
367 If you want to actually see what an object value is, you might try just
369 saying "print $object". That'll get you something like this:
370 Net::FTP=GLOB(0x20154240)
372 or
374 Business::US_Amort=HASH(0x15424020)
376 That's not very helpful if you wanted to really get at the object's
378 insides, but that's because the object value is only a symbol for the
379 object. This may all sound very abstruse and metaphysical, so a real-
380 world allegory might be very helpful:
381 You get an advertisement in the mail saying that you have been
383 (im)personally selected to have the rare privilege of applying for
384 a credit card. For whatever reason, this offer sounds good to you,
385 so you fill out the form and mail it back to the credit card
386 company. They gleefully approve the application and create your
387 account, and send you a card with a number on it.
388 Now, you can do things with the number on that card -- clerks at
390 stores can ring up things you want to buy, and charge your account
391 by keying in the number on the card. You can pay for things you
392 order online by punching in the card number as part of your online
393 order. You can pay off part of the account by sending the credit
394 card people some of your money (well, a check) with some note
395 (usually the pre-printed slip) that has the card number for the
396 account you want to pay toward. And you should be able to call the
397 credit card company's computer and ask it things about the card,
398 like its balance, its credit limit, its APR, and maybe an
399 itemization of recent purchases ad payments.
400 Now, what you're really doing is manipulating a credit card
402 account, a completely abstract entity with some data attached to it
403 (balance, APR, etc). But for ease of access, you have a credit
404 card number that is a symbol for that account. Now, that symbol is
405 just a bunch of digits, and the number is effectively meaningless
406 and useless in and of itself -- but in the appropriate context,
407 it's understood to mean the credit card account you're accessing.
408 This is exactly the relationship between objects and object values, and
410 from this analogy, several facts about object values are a bit more
411 explicable:
412 * An object value does nothing in and of itself, but it's useful when
414 you use it in the context of an $object->method call, the same way that
415 a card number is useful in the context of some operation dealing with a
416 card account.
417 Moreover, several copies of the same object value all refer to the same
419 object, the same way that making several copies of your card number
420 won't change the fact that they all still refer to the same single
421 account (this is true whether you're "copying" the number by just
422 writing it down on different slips of paper, or whether you go to the
423 trouble of forging exact replicas of your own plastic credit card).
424 That's why this:
425 $x = Net::FTP->new("ftp.aol.com");
427 $x->login("sburke", "aoeuaoeu");
428 does the same thing as this:
430 $x = Net::FTP->new("ftp.aol.com");
432 $y = $x;
433 $z = $y;
434 $z->login("sburke", "aoeuaoeu");
435 That is, $z and $y and $x are three different slots for values, but
437 what's in those slots are all object values pointing to the same object
438 -- you don't have three different FTP connections, just three variables
439 with values pointing to the some single FTP connection.
440 * You can't tell much of anything about the object just by looking at
442 the object value, any more than you can see your credit account balance
443 by holding the plastic card up to the light, or by adding up the digits
444 in your credit card number.
445 * You can't just make up your own object values and have them work --
447 they can come only from constructor methods of the appropriate class.
448 Similarly, you get a credit card number only by having a bank approve
449 your application for a credit card account -- at which point they let
450 you know what the number of your new card is.
451 Now, there's even more to the fact that you can't just make up your own
453 object value: even though you can print an object value and get a
454 string like "Net::FTP=GLOB(0x20154240)", that string is just a
455 representation of an object value.
456 Internally, an object value has a basically different type from a
458 string, or a number, or the undefined value -- if $x holds a real
459 string, then that value's slot in memory says "this is a value of type
460 string, and its characters are...", whereas if it's an object value,
461 the value's slot in memory says, "this is a value of type reference,
462 and the location in memory that it points to is..." (and by looking at
463 what's at that location, Perl can tell the class of what's there).
464 Perl programmers typically don't have to think about all these details
466 of Perl's internals. Many other languages force you to be more
467 conscious of the differences between all of these (and also between
468 types of numbers, which are stored differently depending on their size
469 and whether they have fractional parts). But Perl does its best to
470 hide the different types of scalars from you -- it turns numbers into
471 strings and back as needed, and takes the string or number
472 representation of undef or of object values as needed. However, you
473 can't go from a string representation of an object value, back to an
474 object value. And that's why this doesn't work:
475 $x = Net::FTP->new('ftp.aol.com');
477 $y = Net::FTP->new('ftp.netcom.com');
478 $z = Net::FTP->new('ftp.qualcomm.com');
479 $all = join(' ', $x,$y,$z); # !!!
480 ...later...
481 ($aol, $netcom, $qualcomm) = split(' ', $all); # !!!
482 $aol->login("sburke", "aoeuaoeu");
483 $netcom->login("sburke", "qjkxqjkx");
484 $qualcomm->login("smb", "dhtndhtn");
485 This fails because $aol ends up holding merely the string
487 representation of the object value from $x, not the object value itself
488 -- when "join" tried to join the characters of the "strings" $x, $y,
489 and $z, Perl saw that they weren't strings at all, so it gave "join"
490 their string representations.
491 Unfortunately, this distinction between object values and their string
493 representations doesn't really fit into the analogy of credit card
494 numbers, because credit card numbers really are numbers -- even thought
495 they don't express any meaningful quantity, if you stored them in a
496 database as a quantity (as opposed to just an ASCII string), that
497 wouldn't stop them from being valid as credit card numbers.
498 This may seem rather academic, but there's there's two common mistakes
500 programmers new to objects often make, which make sense only in terms
501 of the distinction between object values and their string
502 representations:
503 The first common error involves forgetting (or never having known in
505 the first place) that when you go to use a value as a hash key, Perl
506 uses the string representation of that value. When you want to use the
507 numeric value two and a half as a key, Perl turns it into the three-
508 character string "2.5". But if you then want to use that string as a
509 number, Perl will treat it as meaning two and a half, so you're usually
510 none the wiser that Perl converted the number to a string and back.
511 But recall that Perl can't turn strings back into objects -- so if you
512 tried to use a Net::FTP object value as a hash key, Perl actually used
513 its string representation, like "Net::FTP=GLOB(0x20154240)", but that
514 string is unusable as an object value. (Incidentally, there's a module
515 Tie::RefHash that implements hashes that do let you use real object-
516 values as keys.)
517 The second common error with object values is in trying to save an
519 object value to disk (whether printing it to a file, or storing it in a
520 conventional database file). All you'll get is the string, which will
521 be useless.
522 When you want to save an object and restore it later, you may find that
524 the object's class already provides a method specifically for this.
525 For example, MIDI::Opus provides methods for writing an object to disk
526 as a standard MIDI file. The file can later be read back into memory
527 by a MIDI::Opus constructor method, which will return a new MIDI::Opus
528 object representing whatever file you tell it to read into memory.
529 Similar methods are available with, for example, classes that
530 manipulate graphic images and can save them to files, which can be read
531 back later.
532 But some classes, like Business::US_Amort, provide no such methods for
534 storing an object in a file. When this is the case, you can try using
535 any of the Data::Dumper, Storable, or FreezeThaw modules. Using these
536 will be unproblematic for objects of most classes, but it may run into
537 limitations with others. For example, a Business::US_Amort object can
538 be turned into a string with Data::Dumper, and that string written to a
539 file. When it's restored later, its attributes will be accessible as
540 normal. But in the unlikely case that the loan object was saved in
541 mid-calculation, the calculation may not be resumable. This is because
542 of the way that that particular class does its calculations, but
543 similar limitations may occur with objects from other classses.
544 But often, even wanting to save an object is basically wrong -- what
546 would saving an ftp session even mean? Saving the hostname, username,
547 and password? current directory on both machines? the local TCP/IP
548 port number? In the case of "saving" a Net::FTP object, you're better
549 off just saving whatever details you actually need for your own
550 purposes, so that you can make a new object later and just set those
551 values for it.
552 So Why Do Some Modules Use Objects?
554 All these details of using objects are definitely enough to make you
555 wonder -- is it worth the bother? If you're a module author, writing
556 your module with an object-oriented interface restricts the audience of
557 potential users to those who understand the basic concepts of objects
558 and object values, as well as Perl's syntax for calling methods. Why
559 complicate things by having an object-oriented interface?
560 A somewhat esoteric answer is that a module has an object-oriented
562 interface because the module's insides are written in an object-
563 oriented style. This article is about the basics of object-oriented
564 interfaces, and it'd be going far afield to explain what object-
565 oriented design is. But the short story is that object-oriented design
566 is just one way of attacking messy problems. It's a way that many
567 programmers find very helpful (and which others happen to find to be
568 far more of a hassle than it's worth, incidentally), and it just
569 happens to show up for you, the module user, as merely the style of
570 interface.
571 But a simpler answer is that a functional interface is sometimes a
573 hindrance, because it limits the number of things you can do at once --
574 limiting it, in fact, to one. For many problems that some modules are
575 meant to solve, doing without an object-oriented interface would be
576 like wishing that Perl didn't use filehandles. The ideas are rather
577 simpler -- just imagine that Perl let you access files, but only one at
578 a time, with code like:
579 open("foo.txt") || die "Can't open foo.txt: $!";
581 while(readline) {
582 print $_ if /bar/;
583 }
584 close;
585 That hypothetical kind of Perl would be simpler, by doing without
587 filehandles. But you'd be out of luck if you wanted to read from one
588 file while reading from another, or read from two and print to a third.
589 In the same way, a functional FTP module would be fine for just
591 uploading files to one server at a time, but it wouldn't allow you to
592 easily write programs that make need to use several simultaneous
593 sessions (like "look at server A and server B, and if A has a file
594 called X.dat, then download it locally and then upload it to server B
595 -- except if B has a file called Y.dat, in which case do it the other
596 way around").
597 Some kinds of problems that modules solve just lend themselves to an
599 object-oriented interface. For those kinds of tasks, a functional
600 interface would be more familiar, but less powerful. Learning to use
601 object-oriented modules' interfaces does require becoming comfortable
602 with the concepts from this article. But in the end it will allow you
603 to use a broader range of modules and, with them, to write programs
604 that can do more.
605 [end body of article]
607 [Author Credit]
609 Sean M. Burke has contributed several modules to CPAN, about half of
610 them object-oriented.
611 [The next section should be in a greybox:]
613 The Gory Details
615 For sake of clarity of explanation, I had to oversimplify some of the
616 facts about objects. Here's a few of the gorier details:
617 * Every example I gave of a constructor was a class method. But object
619 methods can be constructors, too, if the class was written to work that
620 way: $new = $old->copy, $node_y = $node_x->new_subnode, or the like.
621 * I've given the impression that there's two kinds of methods: object
623 methods and class methods. In fact, the same method can be both,
624 because it's not the kind of method it is, but the kind of calls it's
625 written to accept -- calls that pass an object, or calls that pass a
626 class-name.
627 * The term "object value" isn't something you'll find used much
629 anywhere else. It's just my shorthand for what would properly be
630 called an "object reference" or "reference to a blessed item". In
631 fact, people usually say "object" when they properly mean a reference
632 to that object.
633 * I mentioned creating objects with constructors, but I didn't mention
635 destroying them with destructor -- a destructor is a kind of method
636 that you call to tidy up the object once you're done with it, and want
637 it to neatly go away (close connections, delete temporary files, free
638 up memory, etc). But because of the way Perl handles memory, most
639 modules won't require the user to know about destructors.
640 * I said that class method syntax has to have the class name, as in
642 $session = Net::FTP->new($host). Actually, you can instead use any
643 expression that returns a class name: $ftp_class = 'Net::FTP'; $session
644 = $ftp_class->new($host). Moreover, instead of the method name for
645 object- or class-method calls, you can use a scalar holding the method
646 name: $foo->$method($host). But, in practice, these syntaxes are
647 rarely useful.
648 And finally, to learn about objects from the perspective of writing
650 your own classes, see the "perltoot" documentation, or Damian Conway's
651 exhaustive and clear book Object Oriented Perl (Manning Publications
652 1999, ISBN 1-884777-79-1).
653
655 Return to the HTML::Tree docs.
656perl v5.32.1 2021-01-27 HTML::Tree::AboutObjects(3)