When to use parentheses around method args?

On Patrick Logan's blog he gives a ruby example in discussing design
trade-offs implementing a visitor/decorator pattern with search trees that
are a mixture of elephants and boxes of elephants.

But I just couldn't work out what the code meant at first - it took me about
5 mins of staring at it before the penny dropped..

# Ruby
class Node
end

class Box < Node
  def initialize
    @children = []
  end
  def << aNode
    @children << aNode
  end
  def num_elephants
    result = 0
    @children.each do |c|
      if c.kind_of? Elephant
        result += 1
      else
        result += c.num_elephants
      end
    end
    return result
  end
end

class Elephant < Node
end

My problem was the the method:

  def << aNode
    @children << aNode
  end

I wondered what is this strange new ruby syntax? But as soon as I saw it
meant this I could follow the code:

  def <<(aNode)
    @children << aNode
  end

It's like one of the 'Escher mind teasers' where you seen a cube from one
perspective, and then suddenly your brain flip-flops to another one.

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

He says it's bad style to use 'if c.kind_of? Elephant', and instead it's
better to expect each node to return a number of elephants. His improved
example expects every node to respond to 'num_elephants', but he makes no
check and so there would be a method_missing execption thrown for a
non-elephant/non-box thing.

I think the second example would be improved by a respond_to? check, but
what if you expected 'elephant aware nodes' to return you a total elephant
weight? Has anyone suggested adding a 'conforms_to?' check in ruby that
checks that an instance will respond_to? an Array of method name symbols?

Then you could query whether a node responds to both 'num_elephants' and
'elephant_weight' by passing an Array like this:

if c.conforms_to? [:num_elephants, :elephant_weight]..

so you could define the protocol as a constant:

ELEPHANT_PROTOCOL = [:num_elephants, :elephant_weight]

if c.conforms_to? ELEPHANT_PROTOCOL..

-- Richard

<posted & mailed>

Richard Dale wrote:

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

I'm trying to retrain myself to _never_ omit the parentheses around argument
lists. It's tough - I like "poetry mode" - but I think the parens make the
code easier to read. Your example is a perfect illustration.

He says it's bad style to use 'if c.kind_of? Elephant', and instead it's
better to expect each node to return a number of elephants. His improved
example expects every node to respond to 'num_elephants', but he makes no
check and so there would be a method_missing execption thrown for a
non-elephant/non-box thing.

I think the second example would be improved by a respond_to? check, but
what if you expected 'elephant aware nodes' to return you a total elephant
weight? Has anyone suggested adding a 'conforms_to?' check in ruby that
checks that an instance will respond_to? an Array of method name symbols?

Frequently. Google comp.lang.ruby for 'duck typing' and be prepared for a
lot of reading. Warning: it's a divisive topic.

Richard Dale wrote:

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

One rule that has been put forth is:

"Use parens in a method call if you are making use of the return value."

So, even though every expression in ruby does return a value, in those cases where you are not interested in it, omit parens if you feel like it.

One case where I almost always omit parens is:

iterator_with_args arg1, arg2 do
   ...
end

(You have to use parens if you use the {...} form instead of do...end.)

In article <cfvmk2$cao$1$8300dec7@news.demon.co.uk>,

On Patrick Logan's blog he gives a ruby example in discussing design

trade-offs implementing a visitor/decorator pattern with search trees that
are a mixture of elephants and boxes of elephants.

Courtesy Implementation

But I just couldn't work out what the code meant at first - it took me about
5 mins of staring at it before the penny dropped..

<snip>

My problem was the the method:

def << aNode
   @children << aNode
end

I wondered what is this strange new ruby syntax? But as soon as I saw it
meant this I could follow the code:

def <<(aNode)
   @children << aNode
end

It's like one of the 'Escher mind teasers' where you seen a cube from one
perspective, and then suddenly your brain flip-flops to another one.

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

When I'm defining an operator method (like '<<' in this example) I always
put in the parens - it's just clearer. Actually, in general when I'm
defining any method I always use the parens. When I call a method,
though, I often omit the parens.

He says it's bad style to use 'if c.kind_of? Elephant', and instead it's
better to expect each node to return a number of elephants. His improved
example expects every node to respond to 'num_elephants', but he makes no
check and so there would be a method_missing execption thrown for a
non-elephant/non-box thing.

I think the second example would be improved by a respond_to? check, but
what if you expected 'elephant aware nodes' to return you a total elephant
weight? Has anyone suggested adding a 'conforms_to?' check in ruby that
checks that an instance will respond_to? an Array of method name symbols?

I must admit I wasn't satisfied with the solution presented there either.
I suppose if you've got a limited number of leaf-type Nodes it's not so
bad, but if you've got lots of leaf types then you have to include more
methods to handle them.

Phil

···

Richard Dale <Richard_Dale@tipitina.demon.co.uk> wrote:

Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:

On Patrick Logan's blog he gives a ruby example in discussing design
trade-offs implementing a visitor/decorator pattern with search trees that
are a mixture of elephants and boxes of elephants.

Courtesy Implementation

But I just couldn't work out what the code meant at first - it took me about
5 mins of staring at it before the penny dropped..
[...]
It's like one of the 'Escher mind teasers' where you seen a cube from one
perspective, and then suddenly your brain flip-flops to another one.

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

In method definitions, I use parens unless there's only one argument.
In method calls, I use parens when I need to, or when omitting them
looks weird.

  mikael

Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

I don't think there are "rules of thumb" for definitions, but assuming
you have a newline after the args (i.e., you're not squashing a whole
def...end on one line or something), parens on def-lines are _always_
redundant, thus I _never_ use them. Perhaps it's just Emacs' syntax
highlighting, but I find it perfectly clear, even for operator-defs
like "def << x".

HTH.

Hi --

My problem was the the method:

  def << aNode
    @children << aNode
  end

I wondered what is this strange new ruby syntax? But as soon as I saw it
meant this I could follow the code:

  def <<(aNode)
    @children << aNode
  end

It's like one of the 'Escher mind teasers' where you seen a cube from one
perspective, and then suddenly your brain flip-flops to another one.

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

Personally I like to adhere as much as possible to the style
established by Matz and the other core developers, though I know this
attitude has lost popularity in recent years. Anyway, if you want to
be a conformist sheep like me, you can use the Ruby distribution as
a source of information about coding style:

# These are almost certainly not 100% correct counts, but they give
# you a very good indication of standard practice. This is
# Ruby 1.8.1.

# All def's:

$ grep "^[[:space:]]*def" `find . -name "*.rb"` | wc -l
   7484

# All the def's with no parentheses:

$ grep "^[[:space:]]*def " `find . -name "*.rb"` | cut -d# -f1 |\
  grep -v "(" | wc -l
   2438

# All of the above which have more than one word other than "def"
# (filtering out one-line defs):

$ grep "^[[:space:]]*def" `find . -name "*.rb"` | cut -d# -f1 | \
  grep -v "(" | grep -v "end$"| ruby -ne "print if split.size > 3" | wc -l
    160

So about 94% of all def's with arguments in the Ruby distribution use
parentheses.

You'll find similar stats for camelCase method/variable names,
indentation by more than two spaces, and other points of style where
Ruby will accept non-conventional practice but conventions and
traditions do exist. How you deal with these things is up to you.

David

···

On Wed, 18 Aug 2004, Richard Dale wrote:

--
David A. Black
dblack@wobblini.net

Tim Hunter wrote:

Frequently. Google comp.lang.ruby for 'duck typing' and be prepared for a
lot of reading. Warning: it's a divisive topic.

No, not really - I don't see this as divisive - what is the opposing
opinion? You can can line up your target ducks with less fuss with my
'conforms_to?' suggestion surely? I've been reading ruby-talk for a while
and haven't noticed any divisive discussions about duck typing..

Tim Hunter wrote:

<posted & mailed>

Richard Dale wrote:

Has anyone suggested adding a 'conforms_to?' check in ruby that
checks that an instance will respond_to? an Array of method name symbols?

Frequently. Google comp.lang.ruby for 'duck typing' and be prepared for a
lot of reading. Warning: it's a divisive topic.

But well worth reading. Also search the archives for 'static typing' and 'interfaces'

James

The sad truth is that my own rule of thumb is vague:

    "Use parens in a method call when it feels right."

The pattern that eventually emerges is that I *don't*
use parens when I want the method call to look like a
field access.

    fruit_salad << tomato.to_fruit
    real_savings -= debt.in_dollars
    puts great_ideas.as_haiku

But I *do* use parens when I want it to be very
obvious that I'm making a method call. So if my method
is using an argument or has a lot of side effects,
I'll probably use parens. Maybe. In my own libraries,
I tend to suffix the method name with "!" if it is
going to have a lot of non-obvious side effects, which
may make parens feel redundant.

    physician.heal(me)
    physician.heal_thyself!

But sometimes I'll throw the whole thing out the
window because I think it makes my code easier to
read. Maybe *that's* my rule of thumb:

    "Use parens whenever it makes it easier for me to
read my own code."

Just thought I'd throw my own stray thoughts into the
mix :slight_smile:

Kind Regards,

Brian Wisti
http://coolnamehere.com/

···

--- Joel VanderWerf <vjoel@PATH.Berkeley.EDU> wrote:

Richard Dale wrote:
> Are there any rules of thumb for when it's a good
idea to leave out the
> brackets and when to use them?

One rule that has been put forth is:

"Use parens in a method call if you are making use
of the return value."

So, even though every expression in ruby does return
a value, in those
cases where you are not interested in it, omit
parens if you feel like it.

One case where I almost always omit parens is:

iterator_with_args arg1, arg2 do
   ...
end

(You have to use parens if you use the {...} form
instead of do...end.)

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Joel VanderWerf wrote:

Richard Dale wrote:

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

One rule that has been put forth is:

"Use parens in a method call if you are making use of the return value."

But instant variables are only accessed through methods; using parens breaks the illusion (for what it's worth) of accessing object state through faux public properties rather than via method calls.

I wonder if people's preferences as to when to use parens has to do with prior experience with languages with a mixed object model (e.g. Java) that allow direct access to object state, versus the messages-only model found in Ruby.

James

Whereas I always use them for defs, since it fits my perception of x as
a placeholding parameter rather than a value.

martin

···

George Ogata <g_ogata@optushome.com.au> wrote:

Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:

> Are there any rules of thumb for when it's a good idea to leave out the
> brackets and when to use them?

I don't think there are "rules of thumb" for definitions, but assuming
you have a newline after the args (i.e., you're not squashing a whole
def...end on one line or something), parens on def-lines are _always_
redundant, thus I _never_ use them. Perhaps it's just Emacs' syntax
highlighting, but I find it perfectly clear, even for operator-defs
like "def << x".

David A. Black wrote:

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

Personally I like to adhere as much as possible to the style
established by Matz and the other core developers, though I know this
attitude has lost popularity in recent years. Anyway, if you want to
be a conformist sheep like me, you can use the Ruby distribution as
a source of information about coding style:

# These are almost certainly not 100% correct counts, but they give
# you a very good indication of standard practice. This is
# Ruby 1.8.1.

# All def's:

$ grep "^[[:space:]]*def" `find . -name "*.rb"` | wc -l
   7484

# All the def's with no parentheses:

$ grep "^[[:space:]]*def " `find . -name "*.rb"` | cut -d# -f1 |\
  grep -v "(" | wc -l
   2438

# All of the above which have more than one word other than "def"
# (filtering out one-line defs):

$ grep "^[[:space:]]*def" `find . -name "*.rb"` | cut -d# -f1 | \
  grep -v "(" | grep -v "end$"| ruby -ne "print if split.size > 3" | wc -l
    160

So about 94% of all def's with arguments in the Ruby distribution use
parentheses.

You'll find similar stats for camelCase method/variable names,
indentation by more than two spaces, and other points of style where
Ruby will accept non-conventional practice but conventions and
traditions do exist. How you deal with these things is up to you.

"Anyway, if you want to be a conformist sheep like me.." - i

Indeed yes I do - whatever is the most socially acceptable and used by
acknowledged experts. It looks like brackets are in.

Your approach is very nice - quoting ruby code that allows you to query ruby
core developer's style programatically. I suppose you could knock up a
Rails site in a few (10?) mins that would allow visual tracking of the
changes to the core developer's style preferences in real time..

-- Richard

Richard Dale wrote:

Tim Hunter wrote:

Frequently. Google comp.lang.ruby for 'duck typing' and be prepared for a
lot of reading. Warning: it's a divisive topic.

No, not really -

Yes, *really*!

I don't see this as divisive -

Oh yes it is!

I'm pulling your leg.

"Ruby needs some way to do static typing" is yet another permathread here. My take on the general argument [0] is that those calling for some sort of type checking believe that duck typing is not robust enough for larger applications, especially as the number of project members grows.

Some folks disagree. This has prompted some lengthy discussions. "Divisive" is subjective, but plausibly applicable.

James

[0] Please do not correct me or start another thread on static typing. Please. Really.

<posted & mailed>

Richard Dale wrote:

Tim Hunter wrote:

Frequently. Google comp.lang.ruby for 'duck typing' and be prepared for a
lot of reading. Warning: it's a divisive topic.

No, not really - I don't see this as divisive - what is the opposing
opinion? You can can line up your target ducks with less fuss with my
'conforms_to?' suggestion surely? I've been reading ruby-talk for a while
and haven't noticed any divisive discussions about duck typing..

Check out the csinterface and the interface projects on RAA. These look
similar to your conforms_to? proposal.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511 is a good
and recent summary of the duck typing issue.

James Britt wrote:

Joel VanderWerf wrote:

Richard Dale wrote:

Are there any rules of thumb for when it's a good idea to leave out the
brackets and when to use them?

One rule that has been put forth is:

"Use parens in a method call if you are making use of the return value."

But instant variables are only accessed through methods; using parens breaks the illusion (for what it's worth) of accessing object state through faux public properties rather than via method calls.

Quite right. Append "...and you are passing arguments." That rule is more or less what I follow in practice.

Martin DeMello wrote:

Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:

> Are there any rules of thumb for when it's a good idea to leave out the
> brackets and when to use them?

I don't think there are "rules of thumb" for definitions, but assuming
you have a newline after the args (i.e., you're not squashing a whole
def...end on one line or something), parens on def-lines are _always_
redundant, thus I _never_ use them. Perhaps it's just Emacs' syntax
highlighting, but I find it perfectly clear, even for operator-defs
like "def << x".

Whereas I always use them for defs, since it fits my perception of x as
a placeholding parameter rather than a value.

That's what I've done so far, but I might try Mikael's suggestion:

Mikael Brockman wrote:

In method definitions, I use parens unless there's only one argument.
In method calls, I use parens when I need to, or when omitting them
looks weird.

But thanks everyone for the comments - I think I need to read more of other
people's ruby code and then judge which style I prefer. If you have a
smalltalk background like Martin Fowler, I suppose the brackets must just
look like noise.

···

George Ogata <g_ogata@optushome.com.au> wrote:

Tim Hunter wrote:

<posted & mailed>

Richard Dale wrote:

Tim Hunter wrote:

Frequently. Google comp.lang.ruby for 'duck typing' and be prepared for
a lot of reading. Warning: it's a divisive topic.

No, not really - I don't see this as divisive - what is the opposing
opinion? You can can line up your target ducks with less fuss with my
'conforms_to?' suggestion surely? I've been reading ruby-talk for a while
and haven't noticed any divisive discussions about duck typing..

Check out the csinterface and the interface projects on RAA. These look
similar to your conforms_to? proposal.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511 is a
good and recent summary of the duck typing issue.

Well I've read that - thanks for the link. I think that discussion is about
error checking, the assumption is that if you are a non-elephant aware node
in the elephant/boxes tree, then it's an error. Either static typing will
trap it, or responds_to? tests or runtime testing.

I don't see that finding a node in the boxes/elephants tree which doesn't
respond_to? the methods ':num_elephants' and ':elephant_weight' is a
problem/error, you just don't try calling it with elephant protocol
methods. 'conforms_to?' is a more convenient way of identifing object
behaviours than anything much to do with error checking.

-- Richard

Hi --

But thanks everyone for the comments - I think I need to read more of other
people's ruby code and then judge which style I prefer. If you have a
smalltalk background like Martin Fowler, I suppose the brackets must just
look like noise.

It's time for us to break the cycle and declare ourselves to have Ruby
backgrounds. As much as we love Ruby, the community suffers from an
inferiority complex: people are constantly doing this or that, or
asking that such-and-such be added to Ruby, because of what is done in
other languages. Yes, Ruby is a modern, combinative language with all
sorts of roots in other languages. But it is not a pastiche; it's a
real language, with a non-trivial userbase and non-negligible history
of usage.

Richard, I certainly don't mean to jump down your throat. For some
reason the spirit happens to move me at this moment to comment on this
in some depth. I've spent almost four years listening to people talk
about "coming from Java" and "being used to Perl" and so on, as
rationales for both unconventional stylistic practices and language
change requests. Sticking just to the former for the moment: I
believe that Matz and his colleagues came up with something really
elegant-looking and consistent as they developed traditional Ruby
style. I think it's a pity to take the style apart and reassemble it
based on isolated decisions about small subsets of it -- especially
when those decisions are made on the basis of practices and
conventions from other languages.

Nor do I mean that things would be better if Ruby programmers started
suggesting that Java drop the {}'s around function definitions because
it would make people coming from Ruby feel more at home. That would
just be more of the same, in the opposite direction. I don't think
Ruby should assert or impose itself like that. What I'd like to see,
rather, is for Ruby to stop being singled out -- by Rubyists -- as
*less* coherent and entitled to its own style and idioms than other
languages.

This is, I should add, completely orthoganal to the question of Ruby
community citizenship and productivity. A number of people who have
contributed vastly more code than I have to the Ruby world use
camelCase method names, def's without parentheses, and all the rest of
it, and I would not buy stylistic uniformity with a single line of
their code. I mean exactly, and only, what I say: it's a pity to have
a beautiful, unifying traditional style and not use it.

David (who "comes from" Ruby :slight_smile:

···

On Thu, 19 Aug 2004, Richard Dale wrote:

--
David A. Black
dblack@wobblini.net

Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:

Martin DeMello wrote:

>> Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:
>>
>> > Are there any rules of thumb for when it's a good idea to leave out the
>> > brackets and when to use them?
>>
>> I don't think there are "rules of thumb" for definitions, but assuming
>> you have a newline after the args (i.e., you're not squashing a whole
>> def...end on one line or something), parens on def-lines are _always_
>> redundant, thus I _never_ use them. Perhaps it's just Emacs' syntax
>> highlighting, but I find it perfectly clear, even for operator-defs
>> like "def << x".
>
> Whereas I always use them for defs, since it fits my perception of x as
> a placeholding parameter rather than a value.
That's what I've done so far, but I might try Mikael's suggestion:

Mikael Brockman wrote:
> In method definitions, I use parens unless there's only one argument.
> In method calls, I use parens when I need to, or when omitting them
> looks weird.

Er, not that it really matters, but I meant to say ``unless the argument
list is empty.''

  mikael

···

> George Ogata <g_ogata@optushome.com.au> wrote: