Slash Boxes
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.
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 [] instead of

    • 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 all out and forgetting about lexicals.

      Re: No arguments had to go any way, but data magically flows back and forth as if the code had never been removed, yeah. I thought the ideal lied more between "not have to change anything" (that case) and "have to change everything" (no time for that, and not that attractive anyway). Where's your Perl refactoring browser when you need it?

      Re: Option 4: write regular classes, but using Class::InsideOut instead of blessed hashref style. Then you retain the benefits of the vars stricture... true. That was worthy of mention. But then I'm changing all of these thousands of variable references. I could probably regex it in vi but still... and as it turns out, I have five variables that are shared between the main program and this object (care of references passed to the constructor).

      Re: 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... yeah, that does need to happen. The larger problem is it's really hard to refactor a program that really needs a lot of different refactors. I'm trying to do one thing at a time. But moving the main program into objecthood will get rid of the $ob->meth vs main::func() dycotomy.

      I can't seem to get straight what the larger problem is. So far...

      1. Fast/Cheap/Good (not Good in this case)

      2. Where to start refactoring something that needs a lot of refactorings

      3. Changing little code at a time and possibily doing bad refactorings in the name of not breaking too much vs. breaking everything but doing it "right".

      4. Am I digging myself into a pit here (so to speak) even though I'm successfully seperating out code and isolating variables (localization of reference, etc)?

      5. Showing this programmer who is new to OO evil hacks or showing that moving some code into an object in Perl requires extensive rework on that code (or some balance of the two).

      Dunno. I'll post what I actually did in a bit here. The only thing I'm sure of is that I'm going to hell.


      • 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.