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.
  • I think you're blindly following a rule here. Sure you might not need it right now, but don't go and design yourself down a dead end. I like to have two lists of features; features we need right now, and features we are going to need soon. You don't want achive something in the first list at the expense of making something in the second very hard.

    Doing the simplest thing possible in a lot of cases is to just return a hash of data. I've found that if you return a blessed hash with proper methods (using C
  • Perl makes this sort of stuff so easy. Generating a quickie little class is trivial, given that there's lots of helper modules on CPAN for it, and you can roll your own with code generation (at runtime) in about 10-15 lines anyway!

    So since it's so easy, why not just do it?
  • You're dead right at one level. My rule of thumb for this is that as soon as I start to manipulate an anonymous array or hash in more than one module then it's time to turn that anonymous structure into its own class. And if I find myself monkeying with it in three modules then that's a definite code smell.
  • I'm not sure I'm qualified to respond to the words of someone with such a high
    GPA, but here goes:

        Though inheritance is usually needless complexity, and functional programming
        with ADTs is the One True Way, using packages in Perl *is* still very
        convenient. It lets you push the functions on your ADT into the namespace of
        that package, instead of having one huge function namespace. So instead of
        oparate_on_foo($foo) and operate_on_bar($
  • 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 da