Method Chaining

[Steven D'Aprano]

On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote:

> To me, it's a toss-up.  The chained version is nice in that it removes the
> repetition of "g".  But the unchained version is more explicit, and avoids
> the awkward parenthesis.
> 
> I think I would lean toward the unchained version.  Clearly tastes can
> differ.

Indeed. For what it's worth, I'm ever-so-slightly leaning towards Lawrence's
taste here. What Michael Selik earlier described as advantages of the
explicit version:

g.move_to((p1 + p2a) / 2)
g.line_to(p1 + (p2 - p1) * frac)
g.line_to((p1 + p1a) / 2)
g.stroke()


namely, "no extra indentation, and no extraneous parentheses", is to me a
negative, not a positive. Since all these commands belong together in some
sense, I like the chained version:

(g.move_to((p1 + p2a) / 2)
  .line_to(p1 + (p2 - p1) * frac)
  .line_to((p1 + p1a) / 2)
  .stroke()
  )


as the parens and indentation more clearly mark this chunk of code as a
unit. On the other hand, I like the fact that methods which are
conceptually procedures that operate by side-effect return None. So it's
hard to decide precisely which behaviour is better. Its very much a matter
of taste.



-- 
Steven