Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Who every said I was designing a large system?

    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.