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.
  • Hi. Where you talk about Damian's recommendation, I think you've got it backwards. On p 93 of his book he says 'avoid using the postfix form of if'. But that's exactly what you're doing!
    Cheers

    • Page 94 says "Reserve postfix if for flow-of-control statements." It's his only exception to the previous guideline.

      • Right, and this is a fancy return, hence control flow. I forgot to clarify that.

  • While clever, I think you've harmed readability rather than helped it by hiding the return in the block. As a reader, I want the flow control statements to be as explicit and obvious as possible so I don't miss them. That's the reason why PBP makes an exception for them in end-of-line conditionals and loops.

    • I can certainly understand that objection. Readability is important, and inventing new control flow "builtins" is a risky business.

      However, it's also possible to reason the other way: I expect any conscientious reader to familiarize themselves with all the local variables in my sub before trying to understand what it does. &flunk_move is one of those local variables; and it happens to be a code block controlling the program flow. Making use of PBP's rule for putting control flow on the left, serves to m

    • This technique is open to abuse, but consider a function with several potential exit points, each of which need to release acquired resources. This technique offers a cleaner approach than a local-goto or cut-and-past resource release blocks.

      • Agreed, to a degree. Carl is trading clarity of control flow for a consistent level of abstraction. As long as the technique is used sparingly and locally, I think it can be a net win.

        But I'll wager that someone will write a Perl6::Critic policy about it in the future, maybe to say that pointy blocks with far-reaching control statements should be simple or not exported beyond the lexical scope.

    • That seems like an odd attitude coming from someone programming in Perl. I know Python programmers who think statement modifiers are a terrible idea in any and all cases on principle. Where did we lose the idea of giving people enough rope to hang themselves if they so desire? Just because this particular abstraction facility is new to you does not make it dangerous. All abstraction facilities have abuse potential – practice shows which ones are very dangerous and which ones can offer enough potential

      • You're preaching to the choir. I'm just on the other end of the style continuum from you, I guess. I work with enough less-experienced programmers to prefer simple solutions, all else being (roughly) equal.

        I'm not saying the practice should be *banned* from the language. I just don't want to see it in any code I must maintain. Action at a distance is the problem -- if the distance is small enough, then it's probably fine. On first read, I personally didn't think the solution was beneficial enough to jus