Loading ...
Sorry, an error occurred while loading the content.

45Re: [extremeperl] Refactorings?

Expand Messages
  • Rob Nagler
    Jul 29, 2002
      chromatic writes:
      > I like this one, especially if you demonstrate that it's reversable.

      I hope to avoid showing the reverse of every refactoring. It maybe
      makes sense to show one or two explicitly.

      > if 'undef' is intended to return a demonstrably false value, this code is a
      > bit broken in list context.
      >
      > my @list = undef;
      > print "True\n" if @list;

      No, you need to check if it is undef. However, I'm going to change
      the example to eliminate the "unless" and "undef" parts. They
      distract from the refactoring which is about statement modifiers.

      > It's very probably not germane to the example, but a book about good Perl
      > development ought to mind context. I generally ask "Did you really mean
      > this?" when I see it during code reviews.

      I think it is inefficient to write:

      return wantarray ? () : undef;

      when the routine returns a scalar. The caller should read the doc or
      code. If you are building large applications in Perl, you need to
      respect the declarations. The unit and acceptance tests will help
      protect against mistakes, but you can't give a kid Perl and say "go
      write an accounting system". Here's a better description of what I mean:

      Java was, as Gosling says in the first Java white paper, designed
      for average programmers. It's a perfectly legitimate goal to
      design a language for average programmers. (Or for that matter for
      small children, like Logo.) But it is also a legitimate, and very
      different, goal to design a language for good programmers.

      See http://www.paulgraham.com/arcll1.html and other articles by Paul
      Graham.

      I think Perl in-the-small is a fine language for just about anybody.
      Perl in-the-large is another beast entirely. You have to respect
      interfaces and have an agreed on coding style. I contend you will
      need OO. You need to build abstractions (e.g. lightweight languages)
      which map domain knowledge succinctly. The power of Perl in-the-large
      is that I can let domain experts program Perl in-the-small with
      "terms" (APIs) developed by Perl experts.

      Rob
    • Show all 14 messages in this topic