The point of omitting parentheses

Ruby
1

Hi there,

I’m fairly new to Ruby, so bear with me. Anyway, on with the question.

What is the benefit of being able to omit parentheses on a method call?
IMHO, parentheses improves readability; I can instantly discern, whether
something is a method call or a variable. It would seem to me, that
readability is, at least, part of the reason for the @-prefix on
instance variables, thus making it difficult for a human reader to
confuse them with local variables. Why not force a similar convention on
method calls, namely explicit parentheses?

In addition, this feature allows you to do stuff like this:

def foo
42
end

foo # -> 42
foo = 1 if false
foo # -> nil

I generally like the language but dead code with side effects makes me
nervous.

Could anyone explain to me, why it’s a good idea to have the option of
omitting parentheses on a method call?

Best Regards,
Henrik S.

2

Hi Henrik,

I’m not sure for the reasoning, but I always parenthesize arguments. I
used to do it for all methods, but I recently started not to use them
for top-level methods like p, puts and print. Anyhow, I’m of much the
same opinion as you are: it makes the code more readible to use them
for method calls, I think.

Regards,
Jordan

3

On 9/20/06, Henrik S. [email protected] wrote:

method calls, namely explicit parentheses?

I generally like the language but dead code with side effects makes me
nervous.

Could anyone explain to me, why it’s a good idea to have the option of
omitting parentheses on a method call?

It allows for nice DSL, c.f Rails’:

class Book < ActiveRecord::Base
has_many :pages
belongs_to :library
end

or, recall the attr_reader:

class Whatever
attr_reader :attr1
end

With mandatory parentheses this would be:
class Whatever
attr_reader(:attr1)
end

4

Vincent F. wrote:

Ruby gives you the freedom to omit parentheses when they are more a
hindrance than a win. Be thankful :wink: !

Hi Vince,

Indeed! That freedom is good! I was only talking about my own personal
style. I actually blogged about this a couple of weeks ago [1], not
that anyone wants to read my stupid ramblings, heh! I like the fact
that ruby allows for using parens or not; that lets each coder find the
best fit for themselves and be more productive! :slight_smile:

[1] Right Foot In: Code formatting

Regards,
Jordan

5

Hello !

I’m not sure for the reasoning, but I always parenthesize arguments. I
used to do it for all methods, but I recently started not to use them
for top-level methods like p, puts and print. Anyhow, I’m of much the
same opinion as you are: it makes the code more readible to use them
for method calls, I think.

I nearly always use parentheses for the functions I define, except the
ones that are to be used from within a class declaration. Those function
calls are more declarations than usual statements. IMHO, it would look
quite ugly to have to write

class Foo
alias(:foo,:bar)
end

Ruby gives you the freedom to omit parentheses when they are more a
hindrance than a win. Be thankful :wink: !

Vince
6

Hi, everybody!

Jan S. писал(а):

With mandatory parentheses this would be:
class Whatever
attr_reader(:attr1)
end

Yes, this would be less attractive than without parentheses, I think.
But. What the rule is? When and where to use parentheses, and where
not?
My point is:

  1. such methods as require, attr_reader, before_filter need no
    parentheses;
  2. such methods as DRb::start_service or join need empty parentheses –
    like start_service() or join();
  3. methods with one String argument like puts “Hello!” or p
    self.inspect need no parentheses;
  4. p with two or more arguments or with one argument of type different
    from String need parentheses.
7

S.Z. wrote:

But. What the rule is? When and where to use parentheses, and where
not?
My point is:

  1. such methods as require, attr_reader, before_filter need no
    parentheses;

Yes.

  1. such methods as DRb::start_service or join need empty parentheses –
    like start_service() or join();

No, they don’t.

  1. methods with one String argument like puts “Hello!” or p
    self.inspect need no parentheses;

Correct again.

  1. p with two or more arguments or with one argument of type different
    from String need parentheses.

Did you bother to check this?

Parentheses are required in Ruby only where ambiutities may occur. This
will trigger a warning as priority may be changed leading to different
interpretations of ambiguous forms. As an example:

a = b = 2 # Set both
p p a, b # Triggers warning

The second line could be read p(p(a,b)) or p(p(a),b). As it happens it
makes no difference in this example which way it is read, but it can be
important. This is the only case where the Ruby language actually
requires parentheses, although in many other circumstances it may be
easier to read with them.

I prefer the lack of parentheses for the first function on a line. I
always parenthesise functions passed as an argument to another even
where only a single argument is taken though.

8

Timothy G. писал(а):

  1. such methods as DRb::start_service or join need empty parentheses –
    like start_service() or join();

No, they don’t.
The motivation follows:
join without parentheses is a function call like self.join, returning
String for Array.
I should add () to emphasize that the join is an action – not a value.
If I wrote join without () this means self.join with self omited.

  1. methods with one String argument like puts “Hello!” or p
    self.inspect need no parentheses;

Correct again.

  1. p with two or more arguments or with one argument of type different
    from String need parentheses.

Did you bother to check this?
Yes I did.
In addition, I do write
print “#{a.inspect}”
insted of
print a.inspect
I think of the reader. Is it axtra-thinking? – may be.

I prefer the lack of parentheses for the first function on a line. I
always parenthesise functions passed as an argument to another even
where only a single argument is taken though.
It is a rule. Thanks.

Respects,
S.Z.

9

Would you really type:

class Foo
attr_accessor( :bar )
end

f = Foo.new()
f.bar=( 12 )
puts( f.bar() )

One of the greatest reasons for omitting parentheses is that the
syntactic sugar allows you to write code that looks like you’re
assigning values to properties and reading those properties, when in
reality you’re calling methods.

f.bar = 12
puts( f.bar )

10

Phrogz wrote:

Would you really type:

class Foo
attr_accessor( :bar )
end

Yes, I would and I’ll tell you why. attr_accessor is a method call.
Vincent F. mentioned alias, which isn’t, but how would I know
that? For example:

class Foo
attr_accessor :foo, :bar
alias :baz, :foo
end

I would expect this to be syntactically correct. It isn’t, though. alias
is a keyword that seems to be syntactic sugar for
alias_method(:baz,:foo)

If parentheses were mandatory the class would look like this:

class Foo
attr_accessor(:foo, :bar)
alias :baz :foo
end

I think that it is clearer in the above code, that there is a difference
between attr_accessor and alias than

class Foo
attr_accessor :foo, :bar
alias :baz :foo
end

Then again, different strokes and all that.

f = Foo.new()

I’d buy that. Guess which language I’m coming from :slight_smile:

f.bar=( 12 )

Ugh. Good point. That you can write f.bar = 12 instead of f.bar=(12) or,
God forbid, f.set_bar(12) is something I really like about Ruby.
However, there are more syntactic sugar at work here. If not, you
shouldn’t really be allowed to write f.bar = 12 and this trick only
works for a small number of “special” methods (-,*,<<,etc) (I think). It
doesn’t seem to be all that big of a deal to make f.bar = something
syntactic sugar for f.bar=(something).

puts( f.bar() )

I’ll buy that too.

One of the greatest reasons for omitting parentheses is that the
syntactic sugar allows you to write code that looks like you’re
assigning values to properties and reading those properties, when in
reality you’re calling methods.

f.bar = 12
puts( f.bar )

I’m all for writing code that is aesthetically pleasing, and to be
honest, I like that you can omit parentheses. What I don’t like is the
quirks it introduces such as the one in the original post. Another
example is

a +b

which may or may not throw an exception depending on whether or not +@
is defined for b, but if the parser decides that a is a method call it
is parsed as a(+b), which probably wasn’t the idea. If the parser
decides that a is a variable it parses it as a.+(b) which is probably
correct. Explicit parentheses would again remove the ambiguity, I think.
This example is in the FAQ and in at least one recent post in here, so I
guess people are actually puzzled by this (with good reason, IMHO).

So it’s really a question of cost vs. benefits. I think the cost is
quite high. Then again, I’m new to Ruby.

Best Regards,
Henrik S.

11

[email protected] wrote:

instance variables, thus making it difficult for a human reader to
foo = 1 if false
fail
etc.

-a

Wow, public, private and protected are actually method call. I wonder
how they implemented that. Now I HAVE to get the source code. :slight_smile:

Best Regards,
Henrik S.

12

On Wed, 20 Sep 2006, Henrik S. wrote:

I generally like the language but dead code with side effects makes me
nervous.

Could anyone explain to me, why it’s a good idea to have the option of
omitting parentheses on a method call?

exit
raise
fail
fork
gets
map{|no_paren| no_paren}
string.to_i
class.new
alias_method
public
private
protected

etc.

-a

13

[email protected] wrote:

On Thu, 21 Sep 2006, Henrik S. wrote:

So it’s really a question of cost vs. benefits. I think the cost is
quite high. Then again, I’m new to Ruby.

i’m going on 7 years of full time ruby and it’s bitten less than 5 times.

Good to know. I don’t really see it as a major problem. I was just
trying to get a handle on the reasoning behind the design choice.

stick with it a while, if you hate it you have the option of putting parens
together with each and every method call - ruby won’t stop you! :wink:

I tend to stick with coding conventions, so if everyone else starts
doing it, I will as well :slight_smile: I’m not convinced that Ruby will be the OOP
language to rule all OOP languages, but it is full of interesting ideas,
many of which I haven’t seen before, so just learning about it helps me
to become a better programmer, even though I might never use it
professionally. I don’t find it trivial to grasp, though. There is a lot
of things going on implicitly, which is both good and bad, mostly good I
think.

Anyway, thanks for the explanations everyone. I got a lot out of it :slight_smile:

Best Regards,
Henrik S.

14

On Thu, 21 Sep 2006, Henrik S. wrote:

So it’s really a question of cost vs. benefits. I think the cost is quite
high. Then again, I’m new to Ruby.

i’m going on 7 years of full time ruby and it’s bitten less than 5
times.
stick with it a while, if you hate it you have the option of putting
parens
together with each and every method call - ruby won’t stop you! :wink:

exit() if Time.now().send(">" carpal_tunnel())

exit if Time.now > carpal_tunnel

-a

15

Henrik S. wrote:

Wow, public, private and protected are actually method call. I wonder
how they implemented that. Now I HAVE to get the source code. :slight_smile:

See if the following helps: code in classes isn’t compiled, it is
executed. Defining a function is a discrete step that runs (and returns
nil), and that you can listen for.

class Foo
def self.method_added( name )
puts “#{self}##{name} just added; it is #{@priv ? ‘private’ :
‘public’}”
end

def self.private
super
@priv = true
end

def self.public
super
@priv = false
end

puts “About to define foo”
def foo; end

puts “About to define bar”
p def bar; end

private

puts “About to define secret_sauce”
def secret_sauce; end
end

#=> About to define foo
#=> Foo#foo just added; it is public
#=> About to define bar
#=> Foo#bar just added; it is public
#=> nil
#=> About to define secret_sauce
#=> Foo#secret_sauce just added; it is private

16

On Sep 20, 2006, at 2:15 AM, Henrik S. wrote:

Hi there,

I’m fairly new to Ruby, so bear with me. Anyway, on with the question.

What is the benefit of being able to omit parentheses on a method
call?

‘(’ and ‘)’ is harder to type than just ’ ’

IMHO, parentheses improves readability; I can instantly discern,
whether something is a method call or a variable.

I don’t like code that looks like this, it is highly unreadable:

foo(bar(arg1), baz(2, arg2))

This is not an improvement:

foo bar(arg1), baz(2, arg2)

This is an improvement:

blah1 = bar arg1
blah2 = baz 2, arg2
foo blah1, blah2

end

foo # → 42
foo = 1 if false
foo # → nil

I generally like the language but dead code with side effects makes
me nervous.

This really is a non-issue. You trip over it once and don’t do it
again.

Could anyone explain to me, why it’s a good idea to have the option
of omitting parentheses on a method call?

It encourages writing readable code by making already unreadable code
even more ugly. There’s a lot of things that are possible to do with
ruby, but are either hard, ugly, or both. They’re that way for a
reason (because you’re probably doing something wrong if you are
doing those things).

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

17

One thing, at least with RoR, is if the first param is a hash then
parens are necessary. e.g.

form_tag({:action=>:update, :id=>1})

I can’t remember what error gets thrown if there aren’t parens.

Myself, I like not having to type parens. RoR’s coding style for patches
specifies using parens though (which is probably best, to avoid
ambiguities or errors).

Joe

18

On Sep 20, 2006, at 9:00 AM, Henrik S. wrote:

Phrogz wrote:

Would you really type:
class Foo
attr_accessor( :bar )
end

Yes, I would and I’ll tell you why. attr_accessor is a method call.
Vincent F. mentioned alias, which isn’t, but how would I know
that?

Because it gives you a syntax error if you try to write it like a
method call.

For example:

class Foo
attr_accessor :foo, :bar
alias :baz, :foo
end

I would expect this to be syntactically correct. It isn’t, though.
alias is a keyword that seems to be syntactic sugar for alias_method
(:baz,:foo)

alias came first, alias_method later.

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

19

The point of being able to omit parentheses is to make it easier to
write Domain Specific Languages (DSLs).The lack of parentheses makes it
easier to create DLSs that consist of declared syntaxes or grammars,
but have the DSL itself still be pure Ruby. Also by parentheses being
optional, we can create a DSL for Ruby itself, in effect creating
constructs which look and act like reserve word extensions to Ruby.

20

On 9/21/06, devdev [email protected] wrote:

The point of being able to omit parentheses is to make it easier to
write Domain Specific Languages (DSLs).The lack of parentheses makes it
easier to create DLSs that consist of declared syntaxes or grammars,
but have the DSL itself still be pure Ruby. Also by parentheses being
optional, we can create a DSL for Ruby itself, in effect creating
constructs which look and act like reserve word extensions to Ruby.

I would say that that’s this year’s ‘point’. For me, I just think
that they are ugly.

I only use them in two places, personally:

  1. When the left-hand side of a ternary starts to look scary:
    x = (foo == baz.something) ? this : the_other

  2. Method definitions, since I find they draw the eye better than
    without.
    def thingy x, y, *z, &block vs. def thingy(x, y, *z, &block)

DSLs are cool, but even if they didn’t exist, I would still want to be
able to omit parens.