Object Oriented Perl

chromatic has brought us yet another pithy programming-book review, this time of Damien Conway's Object Oriented Perl. This sounds like a good book for those interested in not only an overview, but a book that pushes them into at least a few practical applications -- but not one too intimidating to learn from.

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

1. What you need to know first (an object-orientation primer)
2. What you need to know second (a Perl refresher)
3. Getting started
4. Blessing arrays and scalars
5. Blessing other things
6. Inheritance
7. Polymorphism
8. Automating class creation
9. Ties
10. Operator overloading
11. Encapsulation
12. Genericity
13. Multiple Dispatch
14. Persistent objects

Appendices

1. Quick reference guide
2. What you might know instead

Comments

later

[Anonymous Coward]

So long Slashdot my old friend.
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 /. culture and
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

[cloudmaster]

I've been looking for a book with an in-depth discussion of OO under Perl (instead fo a tacked-on chapter that reflects the "tacked-on" opinion of the author). It's nice to see someone wrote one for me. :)

Great book

[sboss]

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

Re:Great book

[Abigail]

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!

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:Great book

[Matchstick]

How utterly useless [Perl OO is]. Granted, for people who don't know what OO is, or have no experience, Perls OO looks great.

If Perl OO were truly useless, there would not be so many stories of pleasant and successful refactorizations (of initial factorizations) of code in this thread. The ad hominem argument against these posters is also not useful. However, your fast food metaphor seems quite apropos. Perl IS the food programming language -- because sometimes you just don't feel like Chez Panisse. Far from making it horrible or useless, this is one of its strengths.

Re:Great book

[the way]

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:Great book

[Abigail]

If I want data hiding, I can have it.

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

Perl != OOPL

[Fat Lenny]

Perl is no more OO than VB or C++...

--

Re:Perl != OOPL

[sohp]

At least Perl (unlike VB) supports inheritance (even multiple, if you're a masochist) and unlike C++, Perl manages memory for you -- no memory leaks.

Re:Perl != OOPL

[keyeto]

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

[codemonkey_uk]

Perl is no more OO than VB or C++

A troll? Perhaps, but he's right, C++ isn't an OOP langauge, its a Multi-Paradigm language, and I would imagine that Perl is the same. Different tools for different jobs. OOP isn't the magic wand the more fanatical members of the OOP comunity might want you to think.

I'f your feeling brave, and want to explore this concept then read Jim Copliens book Multi-Paradig m Design for C++

Thad

Re:Perl != OOPL

[TheCarp]

> 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,

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.

Re:Perl != OOPL

[TheCarp]

> What a joke. No exceptions, no data hiding, weak
> 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:Perl != OOPL

[Camel Pilot]

"the 1970s-era procedural scripting languages"

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:Perl != OOPL

[Abigail]

No Data Hiding? Not fammiliar with closures are you? They make it quite easy to hide your data.

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:Perl != OOPL

[TheCarp]

So you are blaming the language for the faults of
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:Perl != OOPL

[Abigail]

So you are blaming the language for the faults of the people who use it? (ie being lazy).

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

Re:Perl != OOPL

[sohp]

Even Java, Python, Eiffel and Ruby (which, btw, was the precursor to VB) are susceptible to reference leaks of this sort. The mark & sweep method isn't the be-all end-all of GC. How often do you create an object, hand a reference to it to an object of another class not of your creation (a GUI class, e.g.) and then your reference goes out of scope. Later, you may be completely done with the object but it can't be GC'd because some other object still has a now-useless reference to it. Read the book, btw, Perl's GC is a little bit better than Java's (the default GC, not the GC in Hotspot).

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

[Frizzle Fry]

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.

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:Perl != OOPL

[FooBarson]

I wouldn't say "No" memory leaks. The whole point of garbage collection is to allow the programmer to create very complex data structures and not worry about it. Any monkey can match up a "new" and "delete" if they're within the same scope, or if the new is in the constructor and the delete is in the destructor. But, indeed, it does get much more difficult when you start trying have structures with multiple references to a value, and with references to the references, and so on. This is exactly the sort of thing that Perl's "garbage collecting" (reference-counting) doesn't help you with. Matter of fact, Perl's hurts more than it helps, in a lot of cases -- Take copy-on-write memory pages after having fork()'d. If you want to access a portion of memory in Perl, the access alone causes a write to that page, making the program have to copy the page. Et Cetera.

Re:Perl != OOPL

[codemonkey_uk]

Hmm... I think is point is that C++ is hacked together, badly implemented, badly designed, and is so clumsy you have to fight with the language to get the job done, and read tons of books to avoid the hundred pitfalls.

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:Perl != OOPL

[codemonkey_uk]

Many good points made, much of which I agree with, but let me pull you up on a couple:

the necessity to use "virtual"

So you don't pay the cost when you don't use the feature. Without the ability to specify virtual/nonvirtual you can't make a simple 2word/8byte point class without paying another (miniumum) 1 word per instance for rumtime polymorphic methods. The simple fact is runtime polymorphism costs, and sometimes that cost is unacceptable. Arguably this could have been acheaved via the use of a nonvirtual keyword instead, but then I'd be having this same discussion with sombody else.

the need to declare separatly class methods from class definitions

Its called seperation of interface from implementaion, and its a requirement for large scale development. Its also optional in a lot of cases (basically, any situation where a class does not have static data, it can be defined and declared in one place.

RTTI not on by default

Again, its the don't pay for what you don't use principle, and most applications don't need RTTI. (Admitiedly I've been caught by this so I see your point, but if it had been the other way round other people would be complaining!)

templates+overloading funkyness

Templates are a power full tool for creating low runtime cost abstractions, and are the most powerfull tool for enabling reuse that I have ever seen. Overloading also provides the programmer with a powerfull tool for abstraction.

bizarre iterators

Whats bizarre about iterators? There great. Admitedly the syntax is ugly, but I'll have functionality over asthetics every time.

hyper-complexity of STL

Whats complex about a vector? Or a stack? Or a map? It becomes complex when you want to do complex things, but thats better than most librarys, which just don't have the flexability neaded to acheave the complexity at all. But yeah, allocators do suck. =)

unsafe casting

Are you talking about the left over C style casts, or the explicit, documented "unsafe" reenterpret_cast, which is actually usefull if you know what your doing...

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

An excellent Perl book - with one proviso

[Ars-Fartsica]

I highly recommend this book to anyone who is (or thinks they are) a real perl-head. You will undoubtably learn something new about the language.

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!

[Anonymous Coward]

Free Open Source Examples

Short, huh?

[Mike Schiraldi]

Is it me, or was this much shorter than the usual reviews?
--

Re:Short, huh?

[cswiii]

Yeah, seems that way to me. And an ISBN of "http://www.thinkgeek" is neither correct nor helpful.

For those who need it, (ISBN: 1884777791)

Re:Short, huh?

[segmond]

Does length of a review make for a good one? I do not think so. If you don't like short reviews, write a long one and submit it. We will be glad to read. :) Short review is better than no one, besides when a review is posted, I find the most interesting information in comments of those who have read the book.

To Anyone Who Has Read This One

[irix]

I learned my Perl OO from perltoot and the O'Reilly Advanced Perl Programming book.

Does this book provide much more than that?

Re:To Anyone Who Has Read This One

[andy@petdance.com]

I learned my Perl OO from perltoot and the O'Reilly Advanced Perl Programming book. Does this book provide much more than that?

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

[sohp]

Does it? Ever considered blessing a regex? Bet you didn't know that would work! How about writing an extensible double-dispatch handler? Object serialization? Hell yeh it covers a lot more than perltoot!

Re:To Anyone Who Has Read This One

[ftobin]

Does this book provide much more than that?

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.

Re:To Anyone Who Has Read This One

[King Babar]

I learned my Perl OO from perltoot and the O'Reilly Advanced Perl Programming book. Does this book provide much more than that?

Well, you could check out sample chapters on the Manning web-site. 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, 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:To Anyone Who Has Read This One

[kurt1992]

Damian Conway's book blows away the others in its explanations of OO in Perl, and OO in general. If you're a Perl programmer, it is a must read. Especially, if you want to develop serious applications.

This book revamped my Perl OO module creation

[ftobin]

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!

Re:This book revamped my Perl OO module creation

[msuzio]

Class::MethodMaker has been, without a doubt, the most important Perl module ever to my company. Probably even more important than the venerable CGI module (which is nice, but even the author himself seems to always want to move away from it in it's behemoth-ness and go to a set of simpler modules).

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:This book revamped my Perl OO module creation

[drix]

I'm curious how you learned OOP. I'm a self-taught Perl/C hacker who has just never been able to make the leap to object orientation. I know that one of the major benefits of OO is that ideally it is easier to program in because the coding process for objects is a bit more like how we think. For me though, procedural programming just clicks. It's way easier and less muckier than OO, and wierdly enough a lot more intuitive. Mebbe I've just trained myself to think 'procedurally' after all these years. I gather it takes a long time for OOP to fully sink in? It doesn't sound like something I could just sit down and learn, effectively. At any rate, I'm starting EECS at Berkeley next year, so I'm sure after being beat with it for 4 years I'll figger some things out...


--

Yes

[Ars-Fartsica]

This book is really quite extensive and not only explains object oriented perl, but covers the concepts behind OO much more extensively than the other sources you mention.

I'm not particularly impressed with Advanced Perl Programming's coverage of OO.

OO or structured OO?

[jstepka]

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.

Re:OO or structured OO?

[randombit]

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?

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.

Re:OO or structured OO?

[sohp]

No, in fact this book is quite lite on OO as a programming method. You have your basic PIE, but beyond that you need another text. BTW, you should use the 'Preview' button on your post next time.

Shades of 'me too' ...

[LizardKing]

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

Yes, absolutely

[jjohn]

This book not only does a wonderful job exploring OO perl, but does an equally bang up job with exploring other Perl arcana like references to typeglobs. I found this book more practical than the Advanced Perl book.

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.

I scanned this book at B&N, and passed....

[nellardo]

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?

• Using Perl packages as objects? Nope. Got that from the Ostrich.
• Subroutines as methods? Nope. Second thing I did (after twinking a calendar package to use slash's user table and cookies) was create a Slash::Sql wrapper around the "do/execute/fetchrow" nonsense of DBI.
• Persistence? Nope. Third thing I did was make a Slash::Object class, which could read itself from an Sql database, and had an AUTOLOAD corresponding to the columns in the table.
• Multimethods? Okay, this was slightly useful. I caught from skimming the book that there was a multimethod package on cpan. Went there, did a search, then did perl -MCPAN -e "install Class::Multimethod" and I was done.

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 :-)

Re:I scanned this book at B&N, and passed....

[msuzio]

*shakes head*

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.

Re:I scanned this book at B&N, and passed....

[nellardo]

So, msuzio replied to my post, in which I called Perl syntax "opaque":

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,....

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.

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.

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.

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!

Which complexities does Perl lack?

• Strong typing? How many times have you mistakenly put a hash in a scalar context (or vice-versa)? The code goes happily along until, later, you try to look up something in what you thought was a hash (after all, you assigned it a hash), only to get an error that you can't coerce a scalar to a hash?
• Inlines? Nested expressions in Perl and anonymous subroutines got that beat.
• Direct memory access? Tell me that pointer arithmetic is inherently more complicated than the pointer chasing involved in a typical hash/array mix in Perl.
• Templates? Yeah, Perl lacks those, but it lacks those because it lacks strong typing (see above).
• Parameters? Ever do my ($a,$b) = shift; by mistake? After having had one parameter and needing to add a second? How about mixing shift, @_, and other list operations?

I could go on, but my wrists are starting to hurt.

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.

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:I scanned this book at B&N, and passed....

[fornix]

(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 - s

Also check out Apache::Request for an interface to the apache API that automatically parses your forms,etc.

Re:I scanned this book at B&N, and passed....

[msuzio]

No, I haven't taught a CS100 class... but I have taught several people Perl.

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 :-).

Lets here it for Python !!!

[supersnail]

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

[matija]

I'm a CPAN developer (I wrote File::Tail), so I know quite a bit about objects, ties and such.

However, I found this book clear, informative and very much worth the price.

I learned a lot from it.

Objectivity of reviews?

[Anonymous Coward]

I'd take Slashdot's book reviews a lot more seriously if you guys *ever* gave a bad review.

Or ever reviewed a book that you did not sell over at thinkgeek.com.

Re:Objectivity of reviews?

[DrHogie]

Eh, good point. They haven't ever given a bad review, and you'd think that they would ward us away from bad books. Who knows, maybe a review of a Visual Basic book? :P

Re:Objectivity of reviews?

[sql*kitten]

Man, I wish I hadn't posted to this thread so I could moderate that up.

Re:Objectivity of reviews?

[YoJ]

I agree, it would be more fun to see a spectrum of highly rated and lowly rated books. I think that Slashdot doesn't want to focus on unworthy books because there are so many great books out there. I think the most useful "bad" rating reviews would be mediocre reviews of books that have really cool sounding titles. Also, a single "worst of..." collective review might be fun (i.e. reviews of the worst 5 or 6 Java Books).

-Nathan Whitehead

Re:Objectivity of reviews?

[katarn]

I'd take Slashdot's book reviews a lot more seriously if you guys *ever* gave a bad review.

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:Objectivity of reviews?

[jeddz]

I'd take them even more seriously if they didn't point out minor flaws in the book, but still rate it a 10.

If it's got problems, it's not a 10.

--jeddz

Perl is not OO

[sql*kitten]

Some claim the functionality is tacked on, while others insist that it is insecure, impure, and obscure.

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:If OO is so great, why is bulk of GNU/Linux in

[Anonymous Coward]

And don't say OO is best for large scale projects. I know of no larger scale project than GNU/Linux. Surely if C++ and OO was such an advance over C it would have totally replaced nearly all C code by now.

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.

good book

[johnnnyboy]

I purchased this book roughly 3 weeks ago. I'm still in the middle of reading this book. If my free time permits I'll finish it soon. I agree with hemos that this book has a very perlish feel to it (feels just like an orielly book). Full of info and no hype. However, I found the first introduction chapter on OOP way too vague. Since I needed to refresh my OOP skills I referred to my other more indepth texts. Plus the OOP syntax in perl just is not that intuitive. I'm coming from a C++ background so I didn't find OO perl nice. . I had to go through some OO perl tutorials. Now, that I have a general understanding of OO perl I'm now beginning to see how good this book really is. This is definitly not for a novice at Object Oriented programming. This is just my opinion. I came to this conclusion since I really have forgotten quite a bit of OOP concepts. I used to program a lot in C++ but since I began to code in Perl, It's been mostly C style. So the result is pretty sloppy dirty and long code. Hopefully now I can go back to writing cleaner code. :-)

Re:Contradiction in terms?

[Bob Dobbs]

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.

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.

Oxymoron

[warmi]

I think even Cobol is better suited for OO than Perl ...

Re:If OO is so great, why is bulk of GNU/Linux in

[Beethoven]

rewriting an application in C++ bring few benefits.

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.

I, too, learned from pertoot and the leopard book

[freeBill]

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.

Re:Contradiction in terms?

[acb]

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.

If blueberries are blue, y is orange juice orange?

[daninja]

Tough question.

Re:Contradiction in terms?

[Bob Dobbs]

I don't find a well written Perl progam any less messy than a Python program. Again, if it's well written, it's well written. The language has little to do with it. I'll grant you that regular expression that looks like line noise isn't going to be pretty, but that sort of regexp should only be there if it's really needed.

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.

[raistlinne]

Hi,

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.

[Abigail]

As for data encapsulation, which is OO, how does perl's OO not do this?

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

Re:OO is for representing things as objects.

[fornix]

Hello Abigail,
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:OO is for representing things as objects.

[Abigail]

You could do that if you want, to.

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:OO is for representing things as objects.

[fornix]

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.

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!

Perl OO Training Courses?

[Woko]

Are there any courses around that teach this kind of material? I've got the book, but don't seem to be as 'hooked' as the reviewer, and generally it leaves me feeling dead and wishing I was coding in Eiffel again.

Re:If OO is so great, why is bulk of GNU/Linux in

[petchema]

Linux kernel is written in C, but that doesn't mean it doesn't use OOP, only that is doesn't use OOP *language*.

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?

[gaggio]

Hey, there is something like a general thought that I need to discuss with you guys. What the heck are you looking for in books? I have taught myself Perl and created many (powerful) perl programs, but never, never have I needed to read anything in a book. Everything is online, my friends. So why bother buying books? Just for the heck of being part of the "consuming society"? Without me, then! Somebody posted a message about Tom's object-oriented tutorial for perl. THANKS. It is now resting in my reference bookmarks set. You prefer reading stuff on paper? Print it, then. Searching is what people need to learn on the Internet. Because: - the problem you are facing in your programming project has 95% chance of having been faced by somebody before you - searching can be time consuming but with little experience gives you, FOR FREE, all the information, examples, that you need. Of course, don't try to look for relevant information in microsoft knowledge base :-) Ok, back to my sexy Perl program now...

Re:If OO is so great, why is bulk of GNU/Linux in

[elflord]

Firstly, why do you assume that "OO" and "C" are mutually exclusive ? It is certainly possible to write object oriented C ( though it's not pretty )

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:"Object Orientated Perl" LOL! It's a joke right

[elflord]

Perl is not the language of choice for anyone interested in doing some serious OO programming,

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:Contradiction in terms?

[acb]

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.

Re:Contradiction in terms?

[theonetruekeebler]

regular expression that looks like line noise

Ah, but this is object oriented Perl. It's not just line noise, it's encapsulated line noise!

--

Re:"Object Orientated Perl" LOL! It's a joke right

[R.Caley]

Perl is not the language of choice for anyone interested in doing some serious OO programming

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.