Object Oriented Perl 78
| Object Oriented Perl | |
| author | Damian Conway |
| pages | 490 |
| publisher | Manning Publications, 09/1999 |
| rating | 10 |
| reviewer | chromatic |
| ISBN | http://www.thinkgeek |
| summary | Damian Conway demonstrates the elegance of Object Oriented programming in Perl, exposing the flexibility and ingenuity of itsdesign |
The Scoop
A few common myths sully Perl's reputation in the Object Oriented world: Some claim the functionality is tacked on, while others insist that it is insecure, impure, and obscure. Damian Conway handily dispels these rumors in a gem of a book. Though occasionally delving into black magic, Object Oriented Perl is still accessible to novices. Paraphrasing the preface, this book might very well "[lower] cholesterol... [promote] world peace" -- for wizards and initiates alike. (Or at least raise their skills another level.)The Lowdown
The starting point is an introduction to objects and the basic theory behind the OO discipline. This serves as a good overview of the first portion of the book. Following closly is an impressive thirty-page introduction to Perl. As newbies would shortly be overwhelmed, it is not intended as a first look at the language. Rather, it fills in the gaps left by an eclectic education. The chapter ends with a whirlwind tour of more advanced (read, underused) techniques, including the best typeglob discussion I've ever read.Subsequent chapters narrow the focus and intensify the explanation. Conway first introduces three simple rules of Perl objects: classes are packages; methods are subroutines; and objects are blessed referents. While some forks of the trail are quite exotic (blessing a regular expression into an object?), they're all entertaining and very informative.
Programmatic examples follow an iterative and interactive development process, as is common in technical books. The author states a problem and then writes some initial code using a newly explained feature. Refining the program, he demonstrates other ways of achieving the same goal with less code, more features, and better style. Most examples are creative and fairly easily understood (a CD tracking system, a network model), though some, built from computer-science type examples (a pretty printer, a lexer), may be too esoteric for some readers.
As befitting the Perl philosophy, Conway is not hesitent to break with OO tradition as expressed in languages such as C++, Java, Smalltalk, or Eiffel. (Appendix B discusses language features of each with regard to Perl in compact but enlightening technical fashion.) There's an overwhelming sense of Perlishness about the whole thing, and that shines through on every page. Expect to exploit the language's flexibility to achieve amazing results.
By the end of chapter seven, you'll know everything you really need to know to be an effective and productive OO Perl hacker. Luckily, the increasingly specialized information in the last few chapters is optional. You may never use it, but you'll be better for it. As the most extreme example, the Multiple Dispatch chapter explores three rather exotic approaches I've never seen in a Perl program before (dynamic dispatch tables -- armed with this, you could probably write a window manager in Perl). For the paranoid or the purist, a chapter on encapsulation turns Perl's normally lenient access mechanisms around, protecting data through scalars and secure hashes.
The Summary
Superbly organized and excellently explained, this is the definitive book on Object Oriented programming with Perl. Judging from the comments of more qualified experts, we agree that this book belongs on the shelf of any serious Perl hacker. Purchase this book at ThinkGeek.Table of Contents
- What you need to know first (an object-orientation primer)
- What you need to know second (a Perl refresher)
- Getting started
- Blessing arrays and scalars
- Blessing other things
- Inheritance
- Polymorphism
- Automating class creation
- Ties
- Operator overloading
- Encapsulation
- Genericity
- Multiple Dispatch
- Persistent objects
- Quick reference guide
- What you might know instead
later (Score:2)
I won't come to troll you again.
because the console softly creeping,
killed my karma while I was sleeping.
And the flames
with just remnants in my brain,
don't remain,
upon the threads... of Slashdot.
In flick'ring lights I type along.
Submit my troll, before to long,
Letters haloed by my squinting,
at the rant that I was typing.
For my eyes were blurred
by the flash of the cathode beam,
term'nal screen,
and all the trolls... on Slashdot.
And in the fuzzy light I saw
10,000 zealots, maybe more:
Zealots karma farming,
Zealots flaming without thinking.
Zealots modding posts
that karma never shared.
(No one dared,
disturb the balance... of Slashdot)
"Fools," said I, "you do not know.
Honest opinion makes the karma grow.
They post the rules so that we might read them.
Meta mod 'cause we don't heed them."
But my posts
like trolling karma fell,
(Oh well...)
An echo,
On the threads... of Slashdot.
Thanks folks, it's been a blast. After a long time under the TM account, I feel it's time I call it quits. The TM
account was created and used on a bet that a spamming troll could not survive moderation and last more that a
few week, made even harder by having to do it with an account name as silly as Trollmastah.
I'm ending my trollish run with:
* +33 Karma (lowest level I hit was around -20)
* Due to being over +25, I receive the +1 bonus (kind of ironic)
* A long run at -2 default.(Well deserved)
* A console initiated permenant tag which keeps default post at -1 regardless of karma. (sort of a select club)
* About 50/50 percent positive/negative e-mail(Thank you all)
* Easily over 100 "First Posts!"(Woo Hoo!)
Even though trolls are generally discouraged, I did find that trolling is a valuable addition to the
when done without being offensive, vulgar or mean, even trolls can keep positive karma and add not only to the
culture of Slashdot, but also to the content.
I'd like to thank Rob, Jeff and the gang at Andover for providing such a cool forum and for putting up with so
much noise, the daily moderators for participating, and also to the trolls, you add the character which makes
Slashdot a community.
Hope you enjoyed the posts,
Regards,
TM
.
Take all good things in moderation, including moderation.
Finally (Score:1)
Great book (Score:2)
Scott
Scott
C{E,F,O,T}O
sboss dot net
email: scott@sboss.net
I am 39.0% slashdot pure
Perl != OOPL (Score:1)
--
An excellent Perl book - with one proviso (Score:4)
My proviso is this - if you really are interested in object-oriented programming (moreso than simply being a way to write perl, but interested in the methodology itself), then you may want to try Python or another langauge. Perl folks are historically very defensive and perhaps insecure about their OO implementation - Advanced Perl Programming spends chapters explaining to great (and convoluted) pains how Perl's OO approach is superior...but like in Conway's book, you get the notion that it is an apologistic stance.
Don't get me wrong, I love perl and was on the advance list to get Conway's book. While I have my misgivings about OO Perl, this is still a great Perl book and belongs next to the Camel book on any serious PerlMonk's shelf.
Here, this is FREE! (Score:1)
Short, huh? (Score:2)
--
To Anyone Who Has Read This One (Score:3)
Does this book provide much more than that?
Re:Perl != OOPL (Score:1)
This book revamped my Perl OO module creation (Score:3)
If you write serious Perl modules, get this book. I cannot emphasize this enough. I am an author of a couple CPAN [cpan.org] modules, most importantly GnuPG::Interface [sourceforge.net], and I must say that this book entirely revamped my object-oriented Perl module design.
It is the best Perl book I have (and I have quite a few). The most important thing I learned from this book was existence of a very important module, Class::MethodMaker, again available from CPAN [cpan.org]. That module and this book will teach you how to write maintainable, powerful modules. It teaches tieing in a clear manner, what modules are available for use, and what pitfalls to avoid.
I have to repeat this again: if you are a serious Perl module writer, get this book!. You will not regret it!
Re:To Anyone Who Has Read This One (Score:1)
Yes, lots. I learned from those two sources as well, but Conway's book is far more clear and well-presented. I recommend this book unreservedly for anyone who is looking to do more than just string mangling in Perl.
Re:To Anyone Who Has Read This One (Score:2)
Yes (Score:1)
I'm not particularly impressed with Advanced Perl Programming's coverage of OO.
Re:Short, huh? (Score:1)
For those who need it, (ISBN: 1884777791)
Re:To Anyone Who Has Read This One (Score:2)
I cannot emphasize it enough. This book doesn't only tell how to create object-oriented Perl, but how to create strong object-oriented Perl. You will not regret getting this book. This book is my all-time favorite Perl book.
OO or structured OO? (Score:2)
A good place to check out OO design paterns an software would be www.rational.com [rational.com].
Shades of 'me too' ... (Score:2)
And for those who are berating Perl for not being a 'true' OO language, take a look at Objective C, which welds Smalltalk like OO features onto a base language in much the same way that bless() does in Perl. And before you knock Objective C simply because the behemoth that is C++ is currently more
popular, take a look at Mac OS X and OpenSTEP whose API's a largely Objective C based.
Chris Wareham
Yes, absolutely (Score:1)
I too learned from perltoot. That is an excellent beginning.
OO is not needed for every task. But when it is, you'll be glad you have Conway's book.
Re:Perl != OOPL (Score:2)
Well, not quite. Perl manages memory using reference counting, so circular data structures will hang around until the Perl process dies, even if there are no references to the circular data structure left anymore.
This is less serious than the sort of memory leaks you typically get in C, where you are trying to use a reference to a data structure that has been deallocated, or where you never deallocate a data structure nothing can has a reference to. In Perl, the former is never occurs, but the latter does.
However, it's still rather weak, and should be updated to at least perform proper mark and sweep garbage collection, like Ruby, Java, Python, Eiffel, and many others.
A little more on-topic though, I don't like Perl much, but its object orientation is rather well tacked on, even if it's only been tacked on, rather than being a fundamental design decision. In truth, it's the only aspect that encourages me to use the language, whereas there are many aspects that discourage me, not least the way it's not at all easy on the eye.
Furthermore, it's a mistake to think Perl has multiple inheritance, since it is only possible call the constructor of one superclass before blessing the result as an object of the class you're defining. The "multiple inhertance" is much more like the interface mechanism in Java, with the added advantage of being able to provide method bodies.
Re:Perl != OOPL (Score:1)
I'f your feeling brave, and want to explore this concept then read Jim Copliens book Multi-Paradig m Design for C++ [fatbrain.com]
Thad
Re:OO or structured OO? (Score:2)
I think it would be very hard to really learn OO just by learning languages like C++, Perl, or Objective C, where OO features are basically attached onto an existing procedural language. I've been programming C++ about 3 years and still haven't figured it all out (getting there). Maybe better luck is to be had with languages like Python, Smalltalk, Simula, and other such languages [though I have a feeling it wouldn't, for some reason... dunno]
Design Patterns, by Gamma et. al. is probably the book that has helped me with OO the most; it has code examples in C++ and Smalltalk but you really don't need to know either language to understand the book (I have no clue about Smalltalk), as they explain everything in English very clearly, and then use the code just as examples of their methods. I highly recommend it anyone doing OOP in any language.
I scanned this book at B&N, and passed.... (Score:2)
I didn't need the OOP theory (having written a book [http] myself that taught OOP to people without any prior programming experience). I didn't need the Perl introduction (having just forced myself to learn perl after avoiding it for being the blight of a PL that it is (albeit useful) in order to change slash [slashcode.com]). So what did it it offer?
Perl's syntax is often opaque (especially if you didn't already know all the Unix utilities, shell scripting langs and programming langs it is based on). It ispowerful, but this book didn't quite seem to get it all. Closures, non-class-based inheritance (a la Self [sun.com]), or even some more useful examples? (the fourth thing I did was make a Slash::Handler class to interface to Apache, automatically placing query args or form input into fields on itself - subclass and override "handle" to decide what to do) (fifth thing was a subclass of Slash::Handler to use Text::Metatext to generate the page).
A nice enough book, but I think I'm gonna have to write one myself before I see one I really like :-)
Re:To Anyone Who Has Read This One (Score:3)
Well, you could check out sample chapters on the Manning web-site. [manning.com] I also got my perl OO from the sources you mention, but I was impressed with the Conway samples and would buy the book in a minute on impulse if I could find a local bookstore that stocked it.
But I guess a large part of my enthusiasm is driven by the fact that this is a book by Damian Conway, [monash.edu.au] the man, the myth, the crazed hacker, the co-author of "C++ Re-syntaxed", the author of the Coy module, and so on. Seriously, I figure I'd give the guy like $10 if I ever met him in person, so why not just buy all his books and let him have the royalties instead?
Re:OO or structured OO? (Score:1)
Re:Short, huh? (Score:1)
Lets here it for Python !!! (Score:1)
While I am sure the book is an excellent guide to Objectionable Perl, I would question the whole concept of souping up the calling conventions of a procedural language and calling it OO.
This being my major objection to C++ also.
Why screw up a really nice procedural language to produce an unsightly hybryd?
Noe Python on the other hand is a scriting language which is OO from the ground up. You can just about write procedural code if you really try but its much easier to do pure objects, and unlike some OO languages (C++!) you can actually read and understand the resulting code.
Excelent book (Score:1)
However, I found this book clear, informative and very much worth the price.
I learned a lot from it.
Re:Perl != OOPL (Score:1)
> much, but its object orientation is rather well
> tacked on, even if it's only been tacked on,
> rather than being a fundamental design decision.
> In truth, it's the only aspect that
> encourages me to use the language,
Actually....I like perl alot BECAUSE OOP is only
kind of tacked on, rather than a fundamental
design of the language (like java).
While I like using objects et al, for most smaller
and even medium sized things, PERL is a great
language. 99% of the scripts and things I write
have little or no need for the features of OOP.
Mostly write once and run stuff (little tools,
things that check for this or that...admin stuff)
For larger things, I like the ability to grab a
module off CPAN and use its objects. Works
wonders.
I like a language that lets me jump between doing
things in an object oriented manner, right
over to a functional manner. It makes it very
flexible.
I guess thats why perl is called the "Swiss Army
Chainsaw".
> whereas there are many aspects that discourage
> me, not least the way it's not at all easy on
> the eye.
Bad perl code can be horrid to read (true of any
language really, but especially true of perl)
But...you CAN write good, easy to read and
maintain code in perl...its just a matter of being
onsitstant about what you do.
Objectivity of reviews? (Score:1)
Or ever reviewed a book that you did not sell over at thinkgeek.com.
Re:Perl != OOPL (Score:1)
> typing.
No Data Hiding? Not fammiliar with closures are
you? They make it quite easy to hide your data.
> Stick with a language that has modern features
> (strong data types, exceptions, proper data
> visibility)... leave the 1970s-era procedural
> scripting languages "now with faux object
> orientation!" to the virus authors.
Lame. No language features are an excuse for not
learning to program properly.
Also...I doubt highly that Virus authors write
perl code...while it would be easy to do...it
would also be damned silly.
Not everyone programs in the same environment,
with the same groups that you do. No language
is perfect for every job...but PERL is good for
many of them. C and Java each have their place
too.
Re:Objectivity of reviews? (Score:1)
Perl is not OO (Score:1)
Perl is certainly something, and can be made to look vaguely OO like, but that's only likely to appeal to the "OO is just a fancy way to organise your source code" crowd.
Conway is not hesitent to break with OO tradition as expressed in languages such as C++, Java, Smalltalk, or Eiffel.
Errr, right. Now, don't get me wrong, there is definitely a place for doing that, and perl has filled that niche many times since its inception in other areas.
But it is not, and never will be, a strongly typed language with classes, inheritance, polymorphism, encapsulation and abstraction. It wouldn't be perl if it did.
Re:Objectivity of reviews? (Score:1)
Re:Perl != OOPL (Score:1)
O ya and don't use that 50's technology operatoring systems.
Of course your either a pompous ass or a troll or both.
Re:To Anyone Who Has Read This One (Score:1)
Re:If OO is so great, why is bulk of GNU/Linux in (Score:2)
Much of the code is old (this include the GNU tools, most of them were available 10 years ago), and, more importantly, is written to be portable. And also, rewriting an application in C++ bring few benefits.
Re:This book revamped my Perl OO module creation (Score:1)
We've built entire dynamic object systems off of Class::MethodMaker (and adaptations of it's strategy of mucking with the symbol table).
The review and comments convinced me to check out the book, and I'm an old hand at OO Perl. I am constantly amazed that more people do not investigate it, because it is a very nice mix. No, it's not a "tight" OO language like Java... you shouldn't expect that. Instead, it's a nice mix of OO and procedural programming, and *you* get to pick how you want to mix things.
I would have to say, however, that almost none of my Perl programming at this point is procedural. Even simple scripts, as they grow beyond 50 lines or so, seem to adapt much better to an OO approach. I usually follow this approach:
1) If it's a big project (a web app or data import system dealing with many data sources), I immediately code it as OO, after doing some sort of object design (I've just started using UML a lot more)
2) If it's a small project (import one data file into Oracle, analyze one set of log files), I usually hack out something in straight Perl. No subroutines, just top-to-bottom code.
3) As things get more complex from #2, I will factor out subroutines inside the single script
4) If I then need to make #3 more complex (more data sources, etc.) I usually factor out even more code, create an object model, and then end up with a very short script ( 50 lines) that uses the objects to do it's dirty work.
So here, I've mixed OO and non-OO very smoothly... I find it's nice to be able to do that. I'm not sure how well Python would fit this scheme, but it might enable the same sorts of niceness... Certainly, I wouldn't be able to do this in Java, so Java isn't as compelling when the design process is very organic like this, and I might not have the time (or insight into the problem) to design an object model at the start.
Re:I scanned this book at B&N, and passed.... (Score:2)
I do not think (at this point in time) Perl syntax can be considered opaque. It certainly has plenty of strange things as a legacy of how it has grown over it's lifetime, but is this chunk of code so unclear?
use DBI::DBD;
my $dbh = DBI->connect('dbi:Oracle:', 'fooboy/foo@database');
my $file = IO::File->new($inputFileName);
while($in = $file->getlines()) {
$dbh->execute($in);
}
..seems pretty easy to understand to me, once you know the basics that DBI is a database interface layer and IO::File is an object to do IO from files.
In it's basic structure and flow of control, Perl is pretty much the same (to me, at least) as it's close relatives (C, C++, Java). It lacks a lot of the complexities of those (and has plenty of it's own), but it's *not that hard* to learn!
I think, for instance, that Perl is a perfectly easy language to teach in a 100-level CS "Intro to Programming". No prior experience needed.
good book (Score:1)
Re:Contradiction in terms? (Score:1)
I find languages that try to enforce style very irritating. The use of white space in Python, for example, really turns me off to that language.
Re:Great book (Score:2)
Oh, please.
Damians book is a great book. It shows the real face of Perl OO. How horrible it is. How utterly useless. How it is against both OO principles and Perl principles. Granted, for people who don't know what OO is, or have no experience, Perls OO looks great. But for people who want to use OO for the reasons OO is there: data encapsulation and implementation hiding, Damian clearly shows all the hoops, whistles and bells you need to do yourself before you can do so. In fact, to do real data encapsulation and implementation hiding, you have to do so much work yourself that nothing that comes with Perl standard libraries implements this. Nothing. Nada. Zilch.
Perls OO is like MacDonalds food. Fast, cheap, and great if you aren't used to anything else. Kids love it. But utterly disgusting for lovers of gourmet food.
-- Abigail
Re:Perl != OOPL (Score:2)
Care to point out a module in the Perl standard library that uses closures for objects? Or a well known CPAN package?
I hear it all the time. Sure, with Perls OO you can do foo. It's easy! Just bend over backwards this way. Except that noone does it. So, you still can't use someone elses black box, cause noone finds it easy enough to make their box black.
-- Abigail
Re:Objectivity of reviews? (Score:1)
-Nathan Whitehead
Re:Perl != OOPL (Score:1)
the people who use it? (ie being lazy).
And closures aren't really so hard as I would call
them "bending over backwards". They are just not
as commonly known about as they should be.
Besides...not everyone cares about black boxen.
OOP is nice, if thats what you like. However, it
is not the be all and end all of programming.
You don't like PERL...don't use it.
Re:I scanned this book at B&N, and passed.... (Score:2)
So, msuzio [mailto] replied to my post, in which I called Perl syntax "opaque":
First off, let's keep things in context. I said Perl syntax was opaque if you didn't already know the various things it was vased on, which as most Perlmonks know, includes sed, awk, C, sh, csh, C++, Lisp, and Scheme. (for those that don't think Perl draws anything from Lisp or Scheme because it doesn't have all the parens, try looking at "anonymous subroutines" - aka closures (which is what Wall rightly calls them))
Second, opacity of Perl syntax is is obviously something that reduces as you become more familiar with the language. This is complicated by the fact that Perl syntax allows several different ways to do any one thing (a design goal of Perl, of course), which results in a language that lends itself to extreme obvuscation. Consider - a Perl obfuscator could run through Perl code stripping out many local variables, replacing their use with nested expressions, $_, and the like. Flatten some of the subroutines, and make all variable names no more than two characters. A lot of Perl code looks just like this when it is first written - it works but try to get anyone other than the original author to do anything with it. Yes, you can write more engineer-able code in Perl, but you can also write object-oriented assembler.
I'm guessing you have experience in other Algol-based languages, and with some form of shell scripting. Even so, consider the (equivalent):
use DBI::DBD;
for (my ($d,$f)=(DBI->connect('dbi:Oracle:', 'fooboy/foo@database'), IO::File-<new($i);$->getlines();) { $D->execute($_); }
Now suppose you don't know what DBI is. or IO::File. Start throwing regular expressions around and things can get really hairy. This example didn't even start messing with mixes of arrays, hashes, and references.
Which complexities does Perl lack?
I could go on, but my wrists are starting to hurt.
Sounds like you've never actually taught such a class. Try explaining parameter passing. Now try explaining scoping rules. Do you really think you can do that with Perl without driving all your students away?
It may not be so hard for an experienced *nix hacker to learn, but anyone else? C'mon. Be realistic.
Re:Perl != OOPL (Score:2)
In this case, yes. Perl wants the programmer to be lazy. But the lazy way to do OO in Perl is using blessed hash references (and 99% of the examples and code out there uses blessed hash references).
And closures aren't really so hard as I would call them "bending over backwards".
I have no problem using closures. Perhaps you might want to look at my OO::Closures package on CPAN that does OO without using bless (and has full data encapsulation and implementation hiding). However, use of closures for objects is extremely rare - apparently it's too difficult for 99.99% of the Perl coders out there.
Besides...not everyone cares about black boxen. OOP is nice, if thats what you like.
Well, if you don't want to use OO, there's no point in discussing here. My point is that if you want to use OO, Perl isn't a suitable language. 99% of the code that's labelled as OO in Perl is nothing more than abstract datatypes with weak binding. It ain't OO; a '->' token doesn't make OO.
You don't like PERL...don't use it.
Well, it's Perl, not PERL. And I do like Perl. I just don't like the monster they call OO-Perl, because it's neither Perl, nor OO.
-- Abigail
Oxymoron (Score:1)
I think even Cobol is better suited for OO than Perl
Re:If OO is so great, why is bulk of GNU/Linux in (Score:1)
You mean few immediate benefits. C++'s most winsome feature in practice is its excellent support for C, making it in some cases a no-op and always a quick job to convert a C program to C++-compilable form. (NO MORE VARIABLES NAMED "new" AND "class", PLEASE! STOP THE MADNESS!!!!!!) The drawbacks I find in using C++ features are minor losses of portability and GDB support.
Re:Great book (Score:1)
I, too, learned from pertoot and the leopard book (Score:3)
First off, let me get my biases set forward: I believe strongly in OOP. I believe strongly in OO Perl. And I believe strongly in this book, in Damian Conway (who is an excellent educator from Australia), and in the approach he takes to OOP in this book. I believe that OO is an evolving discipline which changes every year. I believe that many OO implementations do a better job of reproducing a snapshot of where OO theory may have been at any one point.
But it is clear to me that Perl's there-is-more-than-one-way-to-do-it (TIMTOWTDI) philosophy does a better job of presenting a dynamic model for implementing any level of OOP that you would like to use for a particular problem. This means you can use it to do true OO programming no matter what you define as "object oriented." This means it can do what you want to do today and what you may not yet know you will want to do tomorrow.
Perl does not force you to do any of it, but it allows you to do whatever you would like. You may have to do some of the work to set it up, but that's the price you pay for the flexibility it allows. Anyone who tells you Perl cannot implement some important aspect of OO probably is doing nothing more than admitting their own ignorance.
Those biases out of the way, the question is: Does this book take it beyond perltoot and "Advanced Perl Programming" (the leopard book)?
The answer is "yes," but it may not be in the way you are looking for. This book is written very much in the spirit of TIMTOWTDI. Each of the chapters lays out all the ways one might approach the subject of the chapter. This gives a variety of solutions to every problem and a very thorough understanding of every issue. If you want an OO system that just tells you the one way you have to do it, then this is not the book for you. But then, Perl is probably not the language for you, either.
Most of the chapters present their solutions in the form of a kind of limited metaclass (essentially abstract classes from which your classes can inherit to acquire the desired functionality). Those familiar with many of the modules on CPAN will recognize this approach.
In general, I found this book to be exactly what I needed to go beyond pertoot and the leopard book. But I would emphasize that I almost never use Damian's code exactly as he presents it. On the other hand, since I have read this book, I have never written a base class which was not based on what I learned from Conway.
It is clear that Damian knows a great deal about OO theory and teaches it well. (This book is also every bit as funny as the camel book.)
The multimethods chapter is a definitive exploration of multiple inheritance. I never use multiple inheritance, but if I ever try it will be based on the CPAN module he explains in this chapter. As has been pointed out elsewhere, this information can be obtained from CPAN as well (but you lose the excellent explanation available here) or from the paper Conway read at last year's Perl Conference.
Summing up: If you understand what I mean by a dynamic model of OO and want to try it, Perl is a good place to do it. If you want to try but are not sure how to implement it, this is the book for you. If you want a static model of OO that holds your hand and makes you behave, then OO Perl is not for you and you should not waste your money on this book.
Re:Perl != OOPL (Score:1)
And just because you can't call the constructor of more than one superclass (actually you can, if you know the right tricks), that doesn't make it non-MI. In Java interfaces only define, well, interfaces, which you must implement. In Perl you can define a class, say, Platypus, and inherit from, say Mammal and Reptile and you will get real, callable methods, say, hasFur() and layEgg(). In Java if you have implement Mammal and Reptile you have to write your own hasFur() and layEgg() methods.
But then, I don't like MI. Try creating a class Osprey and inheriting from Airplane and Helicopter and then calling fly(). My real-world experience with MI in Perl jumped up and bit me, and we re-designed and took the MI out.
Re:Perl != OOPL (Score:1)
Let's not forge Lisp on that list of languages, since it was the first to do it and without it, those other languages might never have had it.
The bus came by and I got on
That's when it all began
There was cowboy Neal
At the wheel
Of a bus to never-ever land
Re:Contradiction in terms? (Score:2)
gross code in any language. I agree that some languages do make it easier to write obsfuscated code, but ultimately the programmer is still one to blame.
Though Perl makes writing neat, easily manageable code on any large scale more of an effort than other languages. And the most carefully written Perl program will still look messier than an equally carefully written program in, say, Python (or Smalltalk or [insert true OO language here]).
Perl was not designed for system development or large-scale coding. You can use it for that, and at some things it excels (processing data, for one), though it is a suboptimal choice. (Have you ever had the feeling of returning to a large Perl project you wrote months ago, say a complex CGI system or such, and almost getting a headache from looking at it?)
If a language makes good design a chore, that is a fault in the language.
If blueberries are blue, y is orange juice orange? (Score:1)
Re:Contradiction in terms? (Score:1)
I return to large perl projects with no problems at all.... Which is why I maintain that writing managable code is the burden of the programmer and not the language.
I don't feel that Perl inflicts any more of a chore for design than Python. I'll grant that if you are a real OO purist, Perl and C++ aren't for you.
OO is for representing things as objects. (Score:1)
OO was made simply to representing data as objects. That is, when the best way to solve a problem is to attack it from the perspective of the objects involved, rather than the actions involved. Simple.
Data hiding is simply a matter of public vs. private APIs. You anounce your public API, you don't anounce your private API, and you make the distinction that anyone using the private API gets what they deserve. Glibc does this, for instance. OO has nothing to do with public vs. private APIs. If the people using your code really don't want to pay attention, a simple #define private public will get your language syntax out of the way as easily as actually using functions with __ preceding them will. Again, implementation hiding is simply a matter of making the distinction between public and private, you don't need the language for that. If you really can't trust your programmers enough to follow the rules, make the damn thing a tcp/ip server or a corba service.
As for data encapsulation, which is OO, how does perl's OO not do this? You define classes, then make objects out of them. Each object has encapsulated data. Simple. It works. Very well, in my experience.
Re:OO is for representing things as objects. (Score:2)
Simple. The typical way (yes, I know how it can be done differently, but let's just ignore the 1% code out there that does it actually different) of making a Perl object is with a blessed hash reference. All your variables associated with that object are put in a hash reference.
Now you want to inherit a class with such an object. Where are you going to put your variables? Right. In the same hash reference. No data encapsulation. No implementation hiding. No private variables.
Or to summerize it: no OO.
Data hiding is simply a matter of public vs. private APIs. You anounce your public API, you don't anounce your private API, and you make the distinction that anyone using the private API gets what they deserve.
The problem is, with Perl, to be able to successful inherit someone elses class, you have to know how the class implements objects. You cannot treat the implementation as a black box and only look at the public API.
Hence, no real OO.
If you really can't trust your programmers enough to follow the rules, make the damn thing a tcp/ip server or a corba service.
It has nothing to do with trust. It has everything to do with programming convenience. I want to be able to take something, obey its API, and then, regardless of what I do, I should not be able to accidentely trample on someones elses variables, or be forced to implement classes the same way as the inherited class was implemented. But the language doesn't give that to me by default; only if I'm lucky and use something whose author went to great trouble keeping their space clean I can do that.
Again, yes, I know it's possible. Damians book shows it's possible. The problem is, Perl's OO is so awkward, it ain't happening. And that's the language fault - not the programmers.
-- Abigail
Perl OO Training Courses? (Score:1)
Re:If OO is so great, why is bulk of GNU/Linux in (Score:1)
It uses the standard way of doing OOP in C, struct* fulls of function pointer, etc. VFS is an obvious example, but most drivers can also be seen as implementations of a virtual class, etc.
And using OOP that way (that is, where needed) surely helps maintainance.
Why bother buying books when everything is there? (Score:1)
Re:Objectivity of reviews? (Score:1)
When I buy technical books, I do so to help solve a problem or learn a new skill. While finding out that a book is "bad" (ignoring the fact that "good" & "Bad" are value judgments) may be helpful, it does not contribute directly towards my goal. Listing a "good" book DOES directly help. Slashdot is not like a newspaper which has lots of room to spare, it only provides 10 or so articles a day. I'd rather the Slashdot article be about a book which will help me, rather then about a book which would be useless to me.
Or ever reviewed a book that you did not sell over at thinkgeek.com.
Maybe, but try look at it the opposite way: If a book is "good enough" to be reviewed on Slashdot, why would you NOT want to sell it on thinkgeek?
Re:Perl != OOPL (Score:1)
Re:If OO is so great, why is bulk of GNU/Linux in (Score:1)
Most of "GNU/Linux" is in C because there's a strong C bias in the traditional POSIX and X/Open APIs. However, OO is dominating the projects that are Linux based, such as GTK/GNOME ( which is OO even though it's predominantly in C ) and KDE.
Re:Great book (Score:1)
Perls OO is like MacDonalds food. Fast, cheap, and great if you aren't used to anything else. Kids love it. But utterly disgusting for lovers of gourmet food.
Conway himself falsifies this statement. He's a very accomplished C++/Java/Smalltalk/etc programmer and computer scientist, and he loves OO Perl. I love OO Perl too, and I've written plenty of OO programs in other, more 'traditional' OO languages.
The great thing about Perl is its flexibility. If I want data hiding, I can have it. If I want derived class data, I can have it. Perl doesn't limit what you can do, it just makes the common things easy. If you want to be sure of avoiding data item clashes, you can get a module to do this. Yes, it's not part of the base distribution, but the CPAN module archive is a core part of the utility of Perl--get what you need, when you need it.
If you can't accept a paradigm other than <insert favorite language here>, then I'm not going to convince you. Creating good OO designs implemented in Perl means doing things the Perl way. Conway shows in his book what the full toolkit of OO techniques is--you can then select what you need for the job.
Empirically, I think there's ample evidence that Perl is a great language for OOP. Personally, I've written a complete UI toolkit for web applications, that includes a substantial inheritance tree, error handling (passed up the inheritance tree), contained objects, etc. I haven't found myself frustrated about any limitations of Perl at all.
And that's the real test, isn't it?
Re:OO is for representing things as objects. (Score:1)
Now you want to inherit a class with such an object. Where are you going to put your variables? Right. In the same hash reference. No data encapsulation.
You could do that if you want, to. Perl gives you the freedom to implement data inheritance and encapsulation however you like. You might decide that instead to used a linked list of blessed tied hases and delegate with AUTOLOAD, FETCH, etc. Whatever floats your boat!
You cannot treat the implementation as a black box and only look at the public API. Yes you can - use a tied hash interface and everything suddenly has to go through an access function! Not awkward in the least.
I like that kind of flexibility and am much more productive with Perl for most things than I was with C++ or Java. But no need for language wars here - just wanted to point some things out.
Re:"Object Orientated Perl" LOL! It's a joke right (Score:2)
What do you mean by "serious OO programming" ? The OO features of perl are quite useful, even if they are "tacked on".
who wants a whole file taken up by every class no matter how small?
Sorry, you've lost me. IIRC, you can put multiple packages in one file.
which is invariably unreadable code which looks something like @foo[--$bar]=~s/$^[3ffkj3n43][[543!x-djf-2]]£jds/% fjfj3[243]fdkjr93432[] unless -e $baz
All this proves is that you have no idea how to write comprehensible code. It's not perl's fault that you're a lousy programmer. You can ( by using a flag ) put white spaces in your regular expressions in the event that you ever do get a regular expression that long and ugly. BTW, can you explain why you think python's regular expressions are more readable than perl's ? How would you do the thing you did above in python ?
Just look at the Slash code for a perfect example, and that's not even got any OO!
Well duh ! That's kind of the point. If you use OO, you can write much cleaner code in perl. Not only doesn't the slash code use OO, it's not terribly clean. You're fooling yourself if you really think that migrating to python automatically relieves you of the obligation to write decent code.
Re:I scanned this book at B&N, and passed.... (Score:1)
Also check out Apache::Request for an interface to the apache API that automatically parses your forms,etc.
Re:This book revamped my Perl OO module creation (Score:2)
--
Re:Contradiction in terms? (Score:2)
Though the choice of language can make manageability easier or harder. Manageability is built into the structure of, say, Python, and comes naturally from it. In Perl, however, writing manageable code requires more effort and discipline; it requires the programmer to specifically concentrate on the task of arranging their code in a manageable way, rather than the myriad other ways Perl is just as happy with.
I'll grant that if you are a real OO purist, Perl and C++ aren't for you.
Oddly enough, I don't find C++ to be anywhere near as messy as Perl. Though I wouldn't call it a proper OO language either; it's more of a code generation tool.
Re:Perl != OOPL (Score:1)
Oh really? Would you mind explaining why?
I can see why you would say "hacked together". (As C++ is an extension of the C langauge, and whilst many (myself included) agree that this is C++'s greatest weekness, it is also considered to be one of its greatest strengths.) What I don't see, and what I find strange in such a hacker orientated forum, is why you consider "hacked together" to be a bad thing.
Implementation is vendor specific, so to say C++ is poorly implemented is a reflection on your supplier, not the language.
Could you explain why, considering the design goals, you consider it to be badly designed.
Finally, what alternative would you recomend, and why.
Of course, I don't expect a reply, because this is just another language bashing AC troll, but I thought I'd say my piece anyway. :)
Thad
Re:Contradiction in terms? (Score:1)
Ah, but this is object oriented Perl. It's not just line noise, it's encapsulated line noise!
--
Re:Objectivity of reviews? (Score:1)
If it's got problems, it's not a 10.
--jeddz
Re:OO is for representing things as objects. (Score:2)
Yes, I know Perl lets you have that. I know Perl very well. And as I said before, I know that if you do a lot of work, you can have implementation hiding and data encapsulation. But you didn't understand my point.
Once again: Perl is making easy things easy, and hard things possible. But within an OO framework, implementation hiding and data encapsulation should be easy. Doing everything with AUTOLOAD and dispatch tables isn't easy. It's hard work!
Whatever floats your boat!
Indeed. Keyword: your. OO is about code reuse. Someone elses code. But, since Perl lets you make objects in a myriad of ways, and makes the implementation part of the API, whether you want it or not, Perl is unsuited as an OO language.
You cannot treat the implementation as a black box and only look at the public API. Yes you can - use a tied hash interface and everything suddenly has to go through an access function! Not awkward in the least.
See, there you said it. use a tied hash. If I want to inherit someone elses class (that's what OO is about, code reuse, remember), and that someone uses just a hash reference (like almost everyone does), you're screwed. That's what I mean with you cannot treat the implementation as a black box. Saying yes you can if it was implemented this and this way is just proving my point; not disproving it.
-- Abigail
Re:Great book (Score:2)
Really? If I write a class, and publish the interface, and you want to use it, how do you know it does data hiding without poking through the source?
Perl isn't a write-only language you know. It's also about using someone elses code. And Perl OO doesn't make that easy at all.
Conway shows in his book what the full toolkit of OO techniques is--you can then select what you need for the job.
Indeed. Write once, use once. Perl OO doesn't at all stimulate code reuse. Any implementation of a class greatly influences how derived classes have to be implemented. That's fine if you want to start from scratch for each project, or are willing to deal with the bagage on a next project. But it doesn't stimulate you to write clean code.
-- Abigail
Re:OO is for representing things as objects. (Score:1)
Well, if your point is that you cannot treat any arbitrary Perl class as a black box, maybe so. In certain cases, you can treat it as a black box, if that's what your design calls for and that's what the author has indicated in his/her documentation. In other cases maybe you want to get at the guts. If you want to inherit from someone's object that was implemented as a hashref, then you do indeed have to be careful. But this is not the fault of the language, but rather the fault of the programmer. Again, you can have black box type data encapsulation and protection on the cheap if you want. And Perl is clearly not the language that is best suited for projects involving big teams. Java/C++ is certainly more suited to that scenario.
"Code reuse" is a desireable goal, but its associated hype is way out of proportion to reality, and it's neither a necessary nor sufficient attribute of productive OO programming. OO is not about "code reuse" - it can be if you design your object model well. But there are always trade offs between trying to make something generalize well (code reuse) and making something that is optimized to the problem at hand. What OO is actually about is binding data and procedures together. If you code reuse is what makes you happy, then you'll love the highly reusable regular expression, hash and string handling code that is built into the Perl language! Those features of Perl, and many more, have probably saved me from needlessly reinventing the wheel more than any Java or C++ class library!
Re:I scanned this book at B&N, and passed.... (Score:1)
Of course you can do nasty things with the language... no doubt. But I think it's a silly argument (constantly presented) to bring out these cases and act like they are *how you have to program*.
You bring up some good examples. Yes, I *have* gotten bitten on at least one of those (the parameter shifting one). I learned from *that* to be more explicit, and now I always do this:
sub foo {
my($a, $b) = @_;
}
or (OO-style)
sub foo {
my($self) = shift;
my($a, $b) = @_;
}
...it's just a matter of discipline, and the fact that I write to a very consistent style. Failure to do so is a problem in any language, isn't it?
...I'll agree with you, though, that Perl can more easily *hide* those sorts of errors. With More Than One Way to Do It, sometimes you run the risk of doing it the Wrong Way
Re:Perl != OOPL (Score:1)
Thanks for the suggestions. Although I'm no fan of Java, I have heard good things about Eiffel, and (when I get time) I'd like to look into it, as well as some of the others you mention.
Thad
Re:"Object Orientated Perl" LOL! It's a joke right (Score:1)
If your primary objective is `serious OO programming' rather than getting some specific job done, then you are seriously in need of a life.
Perl is a language useful for some tasks. OO techniques are a useful tool for handling some types of complexity. If you have a task for which perl is suited and bits have the types of complexity OO ideas are good for, you win.
@foo[--$bar]=~s/$^[3ffkj3n43][[543!x-djf-2]]£jds/% fjfj3[243]fdkjr93432[] unless -e $baz
If you write code like this the problem is you, not the language you choose to dribble in.