Slashdot Mirror
Object Oriented Perl
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
So long Slashdot my old friend.
/. culture and
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.
two weeks ago I had plenty of time on a plane to read (flying east coast to west coast) and I read the first 7 or 8 chapters of this book. I wasn't planning on it but I just could not put the book down. It was great. I have never done OO before although I understood the principals. After reading this book, I not only understand the principals but I can use them. I am now looking at OO'ng all my code now. It makes sense!
Scott
Scott
C{E,F,O,T}O
sboss dot net
email: scott@sboss.net
I am 39.0% slashdot pure
Scott
janitor
sdn website family
email: scott at sboss dot net
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.
Is it me, or was this much shorter than the usual reviews?
--
--
Mod up a post Rob doesn't like and you'll never mod again
Does this book provide much more than that?
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
If you write serious Perl modules, get this book. I cannot emphasize this enough. I am an author of a couple CPAN modules, most importantly GnuPG::Interface, 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. 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!
Everyone knows C++, but not everyone knows OO in the ture fashion. Does this book take you from the design process with an OO architechure which will really drive the OO development or does it just use object while maintaining a structured core?
A good place to check out OO design paterns an software would be www.rational.com.
Justen Stepka
I also wondered whether this book would give me anything above and beyond Advanced Perl Programming.
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
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.
-- "This is the Space Age, and we are Here To Go" - W.S.Burroughs
I didn't need the OOP theory (having written a book 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). 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), 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 :-)
-----
Klactovedestene!
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.
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
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
And I got a lot from this book.
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.
Eternal vigilance only works if you look in every direction.
Obsfuscated Perl is the fault of the programmer, not the language. You can write
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.
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
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.
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.
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.
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