The point of omitting parentheses

ruby-talk
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 Schmidt

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

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

···

On 9/20/06, Henrik Schmidt <nospam@a.b.c.d> 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?
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?

4

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 )

5

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

etc.

-a

···

On Wed, 20 Sep 2006, Henrik Schmidt 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? 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?

--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

6

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

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.

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

···

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

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

7

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.

Henrik Schmidt 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?
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 Schmidt

8

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

9

Hi, everybody!

Jan Svitok писал(а):

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.

···

--
    Best respects, S.Z.

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 Fourmond 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 Schmidt

11

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 Schmidt

···

ara.t.howard@noaa.gov wrote:

On Wed, 20 Sep 2006, Henrik Schmidt 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? 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?

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

etc.

-a

12

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.

···

On 9/21/06, devdev <adeveloper.google@elitefrontier.com> 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.

13

Or hell,

x = 5

If you used parenthesis around every method call, this would be
x=(5)

How does that work, actually? method_missing?

···

On 9/20/06, Phrogz <gavin@refinery.com> wrote:

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 )

14

Vincent Fourmond 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

15

S.Z. wrote:

Hi, everybody!

Jan Svitok писал(а):

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

Yes.

2) such methods as DRb::start_service or join need empty parentheses --
like start_service() or join();

No, they don't.

3) methods with one String argument like puts "Hello!" or p
self.inspect need no parentheses;

Correct again.

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

16

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

···

On Thu, 21 Sep 2006, Henrik Schmidt 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.

--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

17

Henrik Schmidt 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

18

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

···

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

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

19

Like everyone else who has replied to this thread -- they're either
explicitly stated or alluded to the fact that it's purely a matter of
choice.

For me, it's useful to fit my mindset as to what makes things clearer
for me. For years, I have been using Java, and I *do* find the use of
parenthesis around method calls useful in Ruby to make me realise
what's going on. But it's just choice.

When you consider things like:

require 'foo'
attr_reader :myvar

Those dictate properties if you will of the class, so not adding
parenthesis around them makes sense, despite them being methods in
their own right.

-- Thomas Adam

···

On Thu, 21 Sep 2006 23:52:03 +0900 "Wilson Bilkovich" <wilsonb@gmail.com> wrote:

On 9/21/06, devdev <adeveloper.google@elitefrontier.com> 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)

20

Timothy Goddard писал(а):

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

> 3) methods with one String argument like puts "Hello!" or p
> self.inspect need no parentheses;

Correct again.

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