Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
So by your count out of 14 chapters six document outdated or overly tricky features of the Perl OO model (5,8,9,10,11,14). while Five are straight forward useful (1,2,3,4,12) ... and one is useful but advanced (13).
No. By my count, the vast majority of about ten chapters is still directly useful.
By my count that's 35% of the chapters that are directly useful to a Perl5 developer today
By my count, it's 70% still useful. Just because you don't choose to implement a design using Class::MethodMaker, doesn't make learning it useless. Likewise, encapsulation and multiple dispatch. I despair when people think that only the stuff they'll need today is useful. Knowing how others have done things in the past is valuable. Breadth of understanding is worthwhile, even if you never use the techniques shown yourself.

I've heard Damian Conway call that "repertoire" and say how important it is to know a wide range of things, both fundamental and advanced, useful and "tricky". He says it's one of the things that makes a good programmer a great programmer, not just because you know five ways to solve a problem, but also because understanding five ways and their advantages and limitation helps you see why one particular way is better than the other four.

Besides, basing that "flippant remark" on a chapter count (however you choose to count them) is utterly misleading. It assumes all chapters are equally long, which they're certainly not. Might as well say that 1 out of 1 "OO Perl" books contain invalid material, so the book's 100% invalid. Or that 207 of the 283 Moose:: modules have at least open bug report, so Moose is 73% buggy.

In fairness, not all pages are equal either, so basing any evaluation of the book on page counts is misleading too. But at least there are enough pages for the differences to even out, so page counts get nearer the truth than basing an assessment on arbitrary divisions like chapters.

The point isn't that encapsulation is bad, the point is that going out of your way to enforce encapsulation in a language like Perl is simply adding complexity with no benefit. Why double your code when a simple rolled up news paper across the nose is sufficient? "Bad Programmer, No Cookie!"
There's no point arguing this. You could argue exactly the same about (for example) Moose bringing type checking to attribute assignments.

Encapsulation does bring benefits, and can certainly be added to Perl without "doubling the code". Modern inside-out techniques are hardly any more onerous than vanilla hash-based objects, and modules like Object::InsideOut make simple encapsulated classes even less onerous to set up than using Moose.

But given a raw programmer, I'd rather have them learn good OO theory using a proper tool like Moose than I would have to re-teach them all the things I had to forget when I moved from raw Perl OO to Moose three years ago.
You know, it's always respected programmers like yourself who I see advising us beginners to avoid learning all the core stuff that made you excellent programmers excellent in the first place. Knowing how OO Perl actually works, you have the luxury of wishing you didn't, while still enjoying the many subtle benefits of that knowledge. It's almost like a conspiracy by the Perl elite to keep the masses in our proper state of limited understanding. ;-)

Seriously though, understanding how things actually work is important, even when very useful coatings of module-based magic are layered over them. You can't really be great at a language if you don't understand how that language really works, no matter how well you understand any tool built on top of that language. Ultimately, all metaphors break down, and that's just as true of the programming metaphors we call libraries or modules. And, at that point, if you don't understand the mechanism the metaphor is simplifying, you're in deep trouble.

I guess my point is that throw-away remarks that denigrate a dated but well-written book (which still contains, in my view, a lot more than just 1/3 useful information) don't really do justice to the book, to Moose, or to Perl. Or to the many beginners who want to benefit from understanding all three.

In reply to Re^14: OO automatic accessor generation by Anonymous Monk
in thread OO automatic accessor generation by Neighbour

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2023-12-05 14:34 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (27 votes). Check out past polls.