in reply to Re^8: OO automatic accessor generation
in thread OO automatic accessor generation

I wasn't even attempting to duplicate the behavior and I always work with refs for arrays and hashses, so that felt like the natural use here. The point I was making wasn't about your memory. Say you make 5 scripts and hand roll the OO implementation each time. Now instead of one central documented module you have 5 that might have small difference depending on the needs of each. There is no centralized code or process for these OO modules you have created (yes you could create one, and tests and documentation, and that might be the right solution for some cases). So now for each script i have to go read your implementation of the getter/setter and watch for small changes that will bite me. If instead I use Moose then I can read documentation in one location and understand all of the scripts.

Either way my point wasn't USE MOOSE, or anything along those lines. Think of it more as, hey, there might be a solution already built and this one looks pretty spiffy, check it out and see if it fits your needs or not. I've used Moose, and hand rolled OO for different cases and different needs, so it might not be the right tool in this case, but it might be, and for that reason there is no reason not to mention it here in response to the OP.

Eric Hodges

Replies are listed 'Best First'.
Re^10: OO automatic accessor generation
by WizardOfUz (Friar) on Nov 13, 2009 at 15:04 UTC

    I'm sorry. The first paragraph of my previous post was an (obviously failed) attempt to be humorous. I absolutely agree with everything you have written in your last post. I just believe that we should encourage beginners to learn the basics of Perl OOP instead of blindly referring them to Moose. I've seen this kind of dialogue one too many times:

    ImaNewbie: Hi! I've just started using Perl and it's great! I want to get into this OO thing now. I've written some code, but it doesn't work and I really need your help ...

    ... 200 lines of code which took ImaNewbie two hours to write ...

    FatOldMonk: Moose.


      Seriously though, it could be argued that sending people to learn the old, tedious way of Perl OOP first will drive some new users away. Especially with languages like Ruby and Python out there which have nice OO out of the box. Don't get me wrong, I totally think that you should learn your roots, but Perl OOP not only imposes a lot more work but can teach really wrong headed behavior (due largely to its extreme minimalism), just look at like the last 2/3rds of Damians OO book, it is full of overly clever tricks that should never be done in the real world. At some point people just need to get work done.

        just look at like the last 2/3rds of Damians OO book, it is full of overly clever tricks that should never be done in the real world. At some point people just need to get work done.

        Maybe it's been a while since you actually read Damian's OO book, because that's not how it seems to me.

        Of the 14 chapters, the first two give good general introductions to the concepts of OO and the bits of Perl you need to understand to understand OO Perl. The nest five explain the basic way Perl OO works (though Chapter 5--on blessing non-hashes--has a lot of stuff that most developers would never need). Chapter 8 explains two outdated approaches to class creation (i.e. earlier and more easily understood versions of what Moose does now). Chapter 9 explains ties (which certainly are overly clever). Chapter 10 looks at operator overloading (and the last third of the chapter actually counsels against clever tricks). Chapter 11 covers several outdated approaches to encapsulation (which I know you don't consider important, but some of us do). Chapter 12 works through a simple example of polymorphic design. Chapter 13 looks at multiple dispatch (a "trick" so useful that it's now fundamental to, and used everywhere in, Perl 6). The final chapter shows a whole lot of definitely overly clever tricks for creating object persistence mechanisms.

        So there are clearly "overly clever tricks" in chapters 9 and 14, and arguably some in parts of chapters 5, 11, and 13. By my count that's about 100 pages out of 490, or around 20%. Instead of 2/3 of the book being wrong-headed, it seems to me that the first 40% of it is an good solid introduction to the way OO Perl actually works; and that most of the rest of consists of useful, but non-essential, explanation too. Not bad for a book written a decade ago.

        Personally, I'd rather have developers who have read Damian's OO book and therefore understand the underlying Perl OO mechanisms that Moose uses (or sometimes replaces), than have developers who don't understand how Perl OO actually works and just treat Moose as a magic wand.