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

Re: [extremeperl] Refactorings?

Expand Messages
  • chromatic
    ... That s fine. It s important to demonstrate that you don t always go in one direction. ... The bare return operator respects the calling context: sub false
    Message 1 of 14 , Jul 29, 2002
    • 0 Attachment
      On Monday 29 July 2002 22:09, Rob Nagler wrote:

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

      That's fine. It's important to demonstrate that you don't always go in one
      direction.

      > I think it is inefficient to write:
      >
      > return wantarray ? () : undef;
      >
      > when the routine returns a scalar. The caller should read the doc or
      > code.

      The bare return operator respects the calling context:

      sub false {
      return;
      }

      my @list = false;
      my $scalar = false;

      print "list true" if @list;
      print "scalar true" if $scalar;
      print scalar @list;

      Outside of this example, I do agree that explicit interfaces are important for
      large applications.

      > I'm going to change the example to eliminate the "unless" and "undef" parts.
      > They distract from the refactoring which is about statement modifiers.

      I think that's wise. They distracted two of us. ;)

      Regards,
      -- c
    • Ged Haywood
      Hi all, ... 73, Ged.
      Message 2 of 14 , Jul 30, 2002
      • 0 Attachment
        Hi all,

        On Mon, 29 Jul 2002, chromatic wrote:

        > On Monday 29 July 2002 22:09, Rob Nagler wrote:
        >
        > > I'm going to change the example to eliminate the "unless" and "undef" parts.
        > > They distract from the refactoring which is about statement modifiers.
        >
        > I think that's wise. They distracted two of us. ;)

        :)

        73,
        Ged.
      • Rob Nagler
        ... Will do. ... Well, you learn something new everyday. :) Thanks! Rob
        Message 3 of 14 , Jul 30, 2002
        • 0 Attachment
          chromatic writes:
          > That's fine. It's important to demonstrate that you don't always go in one
          > direction.

          Will do.

          > The bare return operator respects the calling context:

          Well, you learn something new everyday. :) Thanks!

          Rob
        • Stephen Nelson
          I ve got a few refactorings on my Perlmonks homenode: http://www.perlmonks.org/index.pl?node_id=2329 There are also references to other refactorings there. I d
          Message 4 of 14 , Jul 30, 2002
          • 0 Attachment
            I've got a few refactorings on my Perlmonks homenode:

            http://www.perlmonks.org/index.pl?node_id=2329

            There are also references to other refactorings there. I'd appreciate
            any feedback.

            Rob Nagler wrote:

            > I'm trying to get an idea what people consider useful refactorings.
            >
            > The following refactoring is a very simple one, but I consider it
            > useful to demonstrate how Perl statement modifiers can be used and to
            > introduce the mechanism by which a document refactorings. The format
            > is borrowed from Fowler's Refactoring book (which I highly recommend,
            > btw).
            >
            > I've got a number of other refactorings in my book, but some have said
            > they are too complicated. I'll send out a few refactorings later
            > after I've got some feedback on the format and what your own
            > refactorings.
            >
            > Thanks for the feedback.
            >
            > Rob
            > ----------------------------------------------------------------
            > TITLE: Replace Conditional with Modifier
            >
            > SYNOPSIS
            >
            > You have an if statement with a one-line then clause.
            > Use a Perl statement modifier to keep data flow on the left.
            >
            > unless (defined($value)) {
            > return undef;
            > }
            >
            > becomes
            >
            > return undef unless defined($value);
            >
            >
            > MOTIVATION
            >
            > This refactoring is controversial, if you aren't used to it.
            > I find modifiers are a useful programming technique, when they are
            > available. We use them in natural language prose where it makes
            > sense. The preceding three sentences are completely normal in
            > English even if they sound weird all in a row. The fact is on
            > the left of a qualifying clause. It puts the action up front so
            > you know what might happen, given a set of circumstances.
            >
            > It's common to use return, last, die, etc. in Perl. Early exits limit
            > the nesting depth. This is a good thing. Modifiers take this one
            > step further by eliminating all nesting, if possible. This keeps data
            > flow on the left, which makes it easier to see the side effects, such
            > as early exit.
            >
            > The roots of programming are based in logic, not in cooking recipes.
            > It seems we often forget this. In mathematical theorems, statements
            > are often followed by qualifying clauses such as such that and iff.
            > Most functional languages put the conditional on the left, which is
            > probably a historical artifact of Lisp, a prefix notation language.
            > In Prolog, rules are expressed as a fact followed by a condition.
            > This refactoring emulates the declarative style of Prolog.
            >
            > You shouldn't use this refactoring to slam as many separate statements
            > into a single line as possible. For example, this is the wrong way to
            > use this refactoring:
            >
            > $x = 39, delete($z{$y}) if $is_tuesday; # WRONG USAGE
            >
            > This line defeats the motivation of keeping the data flow on the left.
            > Too much is happening in one line, and the data operations are
            > complete unrelated. This example obfuscates the data flow instead of
            > improving it.
            >
            > You can convert any if statement into a
            > do-if, e.g.
            >
            > do { # WRONG USAGE
            > $x = 39;
            > delete($z{$y});
            > } if $is_tuesday;
            >
            > This doesn't save nesting. There's more code than a simple if
            > statement. We aren't trying to put all conditionals last. That's as
            > unnatural as ending all conditional English statements with modifying
            > clauses.
            >
            > MECHANICS
            >
            > 1. If the conditional part declares a temporary
            > my variable, move the declaration part out.
            >
            > 2. Remove the braces from the statement and switch the conditional
            > order. Do not change the conditional logic.
            >
            > EXAMPLE
            >
            > Here's a method with two one-line if statements:
            >
            > sub from_literal {
            > my(undef, $value) = @_;
            > unless (defined($value)) {
            > return undef;
            > }
            > $value =~ s/^\s+|\s+$//g;
            > unless (defined($value)) {
            > return undef;
            > }
            > return $value;
            > }
            >
            > We transform the two conditionals into modified statements:
            >
            > sub from_literal {
            > my(undef, $value) = @_;
            > return undef unless defined($value);
            > $value =~ s/^\s+|\s+$//g;
            > return undef unless length($value);
            > return $value;
            > }
            >
            >
            >
            > Yahoo! Groups Sponsor
            > ADVERTISEMENT
            > <http://rd.yahoo.com/M=228862.2128520.3581629.1829184/D=egroupweb/S=1705007181:HM/A=1155069/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-302>
            >
            >
            >
            > To unsubscribe from this group, send an email to:
            > extremeperl-unsubscribe@yahoogroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
            > <http://docs.yahoo.com/info/terms/> .
            > .




            [Non-text portions of this message have been removed]
          • Adrian Howard
            ... [snip] Okay... here s one. (I don t have my Fowler to hand, so please excuse me if I wander off the standard format :-) ... TITLE: HashBecomesObject
            Message 5 of 14 , Jul 30, 2002
            • 0 Attachment
              On Monday, July 29, 2002, at 04:02 pm, Rob Nagler wrote:

              > I'm trying to get an idea what people consider useful refactorings.
              [snip]

              Okay... here's one.

              (I don't have my Fowler to hand, so please excuse me if I wander off
              the "standard" format :-)

              ---

              TITLE: HashBecomesObject

              SYNOPSIS:

              Turn a hash that represents a separate entity into an blessed object
              that reflects it's purpose.

              $Tests->{$class}->{$method}->{num_tests} = 4;
              $Tests->{$class}->{$method}->{type}->{setup} = 1;
              $Tests->{$class}->{$method}->{type}->{teardown} = 1;

              becomes:

              my $info = bless {}, 'Test::MethodInfo';
              $info->{num_tests} = 4;
              $info->{type}->{setup} = 1;
              $info->{type}->{teardown}=1;
              $Tests->{$class}->{$method} = $info;

              MOTIVATION:

              Perl lets you quickly create complex data-structures out of
              hashes-of-hashes, often acting as simple collections.

              These can quickly become hard to comprehend, use and maintain.

              If a part of a hash-of-hashes (or a hash all by it's lonesome) makes
              sense as a separate entity, turn it into an blessed hash.

              This acts as a precursor to things like ExtractClass and allows
              HashAccessBecomesMethodCall for your new object (I'll leave
              HashAccessBecomesMethodCall, and the obvious ObjectBecomesHash as
              exercises for the reader :-)

              ----

              I'm tempted to stick up a perl refactoring wiki (or is there one
              already hiding in a corner somewhere?)... Anybody second the
              suggestion?

              Adrian
              --
              Adrian Howard <adrianh@...>
              phone: 01929 550720 fax: 0870 131 3033 www.quietstars.com
            • Stephen Nelson
              Seconded.... I ve been planning on doing that for way too long. ... [Non-text portions of this message have been removed]
              Message 6 of 14 , Jul 30, 2002
              • 0 Attachment
                Seconded.... I've been planning on doing that for way too long.

                Adrian Howard wrote:

                > On Monday, July 29, 2002, at 04:02 pm, Rob Nagler wrote:
                >
                > > I'm trying to get an idea what people consider useful refactorings.
                > [snip]
                >
                > Okay... here's one.
                >
                > (I don't have my Fowler to hand, so please excuse me if I wander off
                > the "standard" format :-)
                >
                > ---
                >
                > TITLE: HashBecomesObject
                >
                > SYNOPSIS:
                >
                > Turn a hash that represents a separate entity into an blessed object
                > that reflects it's purpose.
                >
                > $Tests->{$class}->{$method}->{num_tests} = 4;
                > $Tests->{$class}->{$method}->{type}->{setup} = 1;
                > $Tests->{$class}->{$method}->{type}->{teardown} = 1;
                >
                > becomes:
                >
                > my $info = bless {}, 'Test::MethodInfo';
                > $info->{num_tests} = 4;
                > $info->{type}->{setup} = 1;
                > $info->{type}->{teardown}=1;
                > $Tests->{$class}->{$method} = $info;
                >
                > MOTIVATION:
                >
                > Perl lets you quickly create complex data-structures out of
                > hashes-of-hashes, often acting as simple collections.
                >
                > These can quickly become hard to comprehend, use and maintain.
                >
                > If a part of a hash-of-hashes (or a hash all by it's lonesome) makes
                > sense as a separate entity, turn it into an blessed hash.
                >
                > This acts as a precursor to things like ExtractClass and allows
                > HashAccessBecomesMethodCall for your new object (I'll leave
                > HashAccessBecomesMethodCall, and the obvious ObjectBecomesHash as
                > exercises for the reader :-)
                >
                > ----
                >
                > I'm tempted to stick up a perl refactoring wiki (or is there one
                > already hiding in a corner somewhere?)... Anybody second the
                > suggestion?
                >
                > Adrian
                > --
                > Adrian Howard <adrianh@...>
                > phone: 01929 550720 fax: 0870 131 3033 www.quietstars.com
                >
                >
                > Yahoo! Groups Sponsor
                > ADVERTISEMENT
                > <http://rd.yahoo.com/M=228862.2128520.3581629.1829184/D=egroupweb/S=1705007181:HM/A=1155070/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-302>
                >
                >
                >
                > To unsubscribe from this group, send an email to:
                > extremeperl-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
                > <http://docs.yahoo.com/info/terms/> .
                > .




                [Non-text portions of this message have been removed]
              Your message has been successfully submitted and would be delivered to recipients shortly.