NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Yes indeed. (Score:1)
This is true. However, I think I can clarify -- if your code needs to be maintained and there is a chance that it might need to be extended in the future, then a little work up front will pay off big time. By putting the behaviours in a class you can avoid action-at-a-distance that might apear later. And yes, 'You Ain't Gonna Need It' is a valid comment. But then again, XP isn't a dogma, its a good starting point.
When behavior starts to creep into your data structure, you risk not Just Doing It Once, so you re-factor into a class. I'm just writing in opposition to premature OO-ification - the root of a couplea kinds of evil.
Absolutely. This was the point I was trying to make before. If you need nothing but the behaviours of an Array or a Hash, thats fine, but if there is a need for other behaviour, then create a container. I have a rule of thumb that I often apply -- if I need to use a hash or an array outside of my immediate scope a flag goes up and I need to look to see if there are behaviours that can be refactored into a class.
When all is said and done, Perl's hash and array types are abstractions. In general it would be nice to treat them like any other abstraction, however, Perl doesn't provide them as first class objects, which is a pity.
Reply to This
Mwah hah hah ha! (Score:1)