[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

the point of omitting parentheses

Henrik Schmidt

9/20/2006 9:11:00 AM

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
26 Answers

MonkeeSage

9/20/2006 9:33:00 AM

0

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

Jano Svitok

9/20/2006 9:42:00 AM

0

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?

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

Vincent Fourmond

9/20/2006 9:44:00 AM

0


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

Vince

MonkeeSage

9/20/2006 10:43:00 AM

0

Vincent Fourmond wrote:
> Ruby gives you the freedom to omit parentheses when they are more a
> hindrance than a win. Be thankful ;-) !

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! :)

[1] http://rightfootin.blogspot.com/2006/09/code-forma...

Regards,
Jordan

S.Z.

9/20/2006 11:41:00 AM

0

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.

Timothy Goddard

9/20/2006 12:41:00 PM

0

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.

S.Z.

9/20/2006 1:30:00 PM

0

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.

Gavin Kistner

9/20/2006 2:07:00 PM

0

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 )

Ara.T.Howard

9/20/2006 2:31:00 PM

0

Henrik Schmidt

9/20/2006 3:59:00 PM

0

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

> 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