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.
  • Dear goodness, that sounds like a Frankensteinian creation.

    passing all of the variables back and forth to a subroutine would have been tedious, verbose, and error prone.

    Sounds like you might want a parameter object. (See Refactoring.)

    No arguments had to go any way, but data magically flows back and forth as if the code had never been removed.

    Evil. And not in a good way. Evil evil evil.

    I have two choices here, ignoring that.

    Option 4: write regular classes, but using Class::InsideOut [cpan.org] instead of blessed hashref style. Then you retain the benefits of the vars stricture.

    So the main package keeps doing things like $ob->something() but the object does main::func().

    Agh. I’m not sure what to recommend here, except to say I think the existing structure is decidedly awful. Probably what you want to do is push all the code in the main program into a class of its own, then leave just a stub for the main program that does some setup and then enters a loop or calls $worker->run or whatever.

    It’s hard to give informed and useful recommendations without you showing any code, though.


    • Heh...

      Re: Sounds like you might want a parameter object. (See Refactoring.), yeah. I considered that. I looked at different ways I could group the data into different objects and decided that, by necessity, it's all too mixed together so I'd wind up with one big one. And I didn't want to change everything from $foo to $ob->foo. And then three different modules would be using all of the variables, so having a parameter object wouldn't be much of a win over just making them "global", or exporting them
      • It’s hard to refactor a large ball of mud into something sane, I’ll give you that. Doing that with the occasional evil hack is OK, so long as its use is only transitory; by the end of the process, the code should be straightforward. If you are left with deep magic in code whose purposes are quite pedestrian, chances are you did something wrong.

        As for the coworker: for one thing, moving code towards an OO design inevitably requires a pretty extensive rework. The language is a red herring here;


        • Re: moving to OO requiring extensive rework, true enough. Re: language being a red herring, I don't care for $foo vs $self->{foo} or $foo{$self}, but if anything, Perl gives me too many options (ref swiss army chainsaw) ;)

          Re: technical debt, the client in question is a startup that's strategically trying not to run out of money before the code is done. But there's one bit of difficulty -- the code isn't done until an external agency decides its done. I should have listed that in my "the real problem"
          • Augh. If they racked up too much technical debt, it may in fact be impossible to complete the technical downpayment before it causes financial bankruptcy…

            I don’t have any easy solutions.

            And yeah, Perl’s overly-DIY OO system is the one serious weakness I see, despite the oft-mentioned fact that it can also be a strength. When real work is on the table you don’t want to start fiddling with a construction set first.