Re^8: OO automatic accessor generation

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

Can you tell me the answers to those questions without checking the implementation?

Yes, of course. I've just written that code. I'm somewhat forgetful, but it's not that bad ...

Apart from that, maybe my hint was too subtle, but I think your sample code behaves quite differently from the OP's code. Shouldn't you have set the auto_deref option to true for your ArrayRef and HashRef accessors? Then again, maybe I'm not remembering this correctly. You know ... that memory thing ;-)

Comment on Re^8: OO automatic accessor generation Select or Download Code

Replies are listed 'Best First'.
Re^9: OO automatic accessor generation by stvn (Monsignor) on Nov 12, 2009 at 20:42 UTC
Apart from that, maybe my hint was too subtle, but I think your sample code behaves quite differently from the OP's code. Shouldn't you have set the auto_deref option to true for your ArrayRef and HashRef accessors? Yes, you are correct, but even that would not work exactly the same. The OP's code (as well as your refactoring) would return an array count in scalar context (or that odd fraction looking string that you get when you do `scalar %foo` that tells you about the buckets and keys of the HV), where auto_deref in Moose would return an array reference or hash reference. Honestly, this to me is just another reason to use Moose since this behavior is sane, documented and tested, all a user would need to do would be to check those docs. Using the hand-rolled code, a simple accident of context (a common gotcha for Perl beginners) could lead to a very confusing debugging session and non-obvious perldoc hunt. I am sure even you would agree that seeing something like "HASH(0xDECAF)" is easier to figure out then "3/12". One of the things about Moose that I suspect you are not seeing is that it brings consistency to Perl OO and that is a good thing. If 100 programmers write a Perl classes using Moose and use auto_deref, then any of those 100 programmers could look at any of those 100 classes and know exactly what auto_deref means and how it will behave. Additionally all these 100 classes would be (within reason) compatible with one another since they would all be using the same underlying object system making it easier for people to reuse them. If just 10 programmers write a Perl class using their hand-rolled object system the odds that any of those 10 systems would be compatible with one another are not very good. The odds are very good that at least one of those hand-rolled object systems would have issues with inheritance and some of them will make mistakes like the OP and do something like regenerate accessors in the constructor. Writing an object system in Perl is easy and fun, but writing a robust and flexible object system in Perl is hard and is only fun if your a masochist. -stvn	[reply] [d/l]
Re^9: OO automatic accessor generation by eric256 (Parson) on Nov 12, 2009 at 20:31 UTC
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	[reply]
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.	[reply]
Re^11: OO automatic accessor generation by stvn (Monsignor) on Nov 13, 2009 at 19:05 UTC
FatOldMonk++ 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. -stvn	[reply]
Re^12: OO automatic accessor generation by Anonymous Monk on Nov 13, 2009 at 20:57 UTC
Re^13: OO automatic accessor generation by perigrin (Sexton) on Nov 17, 2009 at 23:42 UTC
Some notes below your chosen depth have not been shown here

In Section Meditations