mandatory braces

[Johannes Ahl-mann]

hi,

i've been playing around with ruby a bit and have a proposal to make.
i am sure that ruby won't adopt it right away and maybe it goes too much
against the ruby way. also, if this has been discussed earlier here, i
apologize for not researching ;-))

if ruby made braces (the round ones ;-) mandatory this would produce
some very nice effects and break nothing except for backward compatibility
(i think). regarding the backward compatibility one could even introduce
a new command-line switch to explicitely activate the "new" syntax.
a few things would become possible:

- differentiation between method bindings and method applications, i.e.
"function1(function2)" instead of "function1(methodfunction2))
- procedure objects could be treated similarly to functions:
"myproc()" instead of "myproc.call()"
- ruby code would look more uniform, because at the moment the mixing
of braces and no-braces drives me crazy *gg*

- on the negative side this would force braces for methods "yield",
"print", "puts", "break", etc.

please tell me whether this is a bad idea,

Johannes

 

[Alexander Kellett]

please tell me whether this is a bad idea,

lets put it this way.
if this went into ruby,
i'd fork

Alex

 

[David A. Black]

Hi --

hi,

i've been playing around with ruby a bit and have a proposal to make.
i am sure that ruby won't adopt it right away and maybe it goes too much
against the ruby way. also, if this has been discussed earlier here, i
apologize for not researching ;-))

if ruby made braces (the round ones ;-) mandatory this would produce
some very nice effects and break nothing except for backward compatibility
(i think). regarding the backward compatibility one could even introduce
a new command-line switch to explicitely activate the "new" syntax.
a few things would become possible:

- differentiation between method bindings and method applications, i.e.
"function1(function2)" instead of "function1(methodfunction2))
- procedure objects could be treated similarly to functions:
"myproc()" instead of "myproc.call()"

I don't think that's desireable, and probably not feasible. Consider:

def x; end
x = lambda {}
x() # which is it?

Not an example of great programming, but definitely legal.

- ruby code would look more uniform, because at the moment the mixing
of braces and no-braces drives me crazy *gg*

- on the negative side this would force braces for methods "yield",
"print", "puts", "break", etc.

please tell me whether this is a bad idea,

It's a bad idea

I agree that the mixing of styles looks bad, and I wish people would
stick reasonably close to traditional style, which generally does not
use empty parens except for super(), one-line method definitions, and
meth() as an alternative to self.meth. I fear that that battle is
being lost on several fronts (camelcase, extra (), tab stops more than
2, etc.), but I still root for it.

Anyway -- in addition to adding visual clutter, and being redundant
(since the . already means that a method is going to be called), I
think mandatory () would weaken attribute/accessor semantics. You'd
end up with:

person.age()

which just shouts "This is a method call with zero arguments!" without
adding any new information, since

person.age

already tells you that. (Assuming there's no argument after it


David

 

[Nikolai Weibull]

* Johannes Ahl-mann (Feb 13, 2005 15:20):

braces (the round ones ;-)

Parentheses, please,
nikolai

 

[Bertram Scharpf]

Hi,

Am Sonntag, 13. Feb 2005, 23:14:57 +0900 schrieb Johannes Ahl-mann:

if ruby made braces (the round ones ;-) mandatory this would produce
[...]
please tell me whether this is a bad idea,

I'd rather appreciate a way to get rid of the rest of
parentheses that don't mean expression grouping.

Bertram

 

[Nikolai Weibull]

* Bertram Scharpf (Feb 13, 2005 19:00):

I'd rather appreciate a way to get rid of the rest of parentheses that
don't mean expression grouping.

:-D,
nikolai

 

[craig duncan]

hi,

i've been playing around with ruby a bit and have a proposal to make.
i am sure that ruby won't adopt it right away and maybe it goes too much
against the ruby way. also, if this has been discussed earlier here, i
apologize for not researching ;-))

if ruby made braces (the round ones ;-) mandatory this would produce
some very nice effects and break nothing except for backward compatibility
(i think). regarding the backward compatibility one could even introduce
a new command-line switch to explicitely activate the "new" syntax.
a few things would become possible:

- differentiation between method bindings and method applications, i.e.
"function1(function2)" instead of "function1(methodfunction2))
- procedure objects could be treated similarly to functions:
"myproc()" instead of "myproc.call()"
- ruby code would look more uniform, because at the moment the mixing
of braces and no-braces drives me crazy *gg*

- on the negative side this would force braces for methods "yield",
"print", "puts", "break", etc.

please tell me whether this is a bad idea,

Johannes

I agree (with others) that this exact idea isn't so good. Why should you have to use
parens when a method has no args? But the one flaw that has bothered me about ruby
is that _too much_ flexibility in parsing is allowed. I'd like it if parens were
required around a method call's arguments. The savings in leaving them off i find
less than desirable as i (personally) find it _harder_ to parse things out, visually.
Not to mention that i think the following is ridiculous:

s='abc'
=> "abc"
irb(main):002:0> (s.length -1).downto(0) { |i| p i }
ArgumentError: wrong number of arguments (1 for 0)
from (irb):2:in `length'
from (irb):2
irb(main):003:0> (s.length - 1).downto(0) { |i| p i }
2
1
0
=> 2

 

[Joao Pedrosa]

Hi,

I agree (with others) that this exact idea isn't so good. Why should you have to use
parens when a method has no args? But the one flaw that has bothered me about ruby
is that _too much_ flexibility in parsing is allowed. I'd like it if parens were
required around a method call's arguments. The savings in leaving them off i find
less than desirable as i (personally) find it _harder_ to parse things out, visually.
Not to mention that i think the following is ridiculous:

I think that one of the things that make Ruby what it is is the
general flexibility of its syntax. The other day I saw this in an
example for Rails:

{= foo.flash['bar'] if foo.flash['bar'] }

or Something... See? The flexibility paid off for the guy that wanted
to use it like that.

I generally avoid such constructions, mind you. But I know that one
line is better than 3 lines, depending on the situation.

If you take a look at the code of Rails you will see code evaluations
and whatnot that are much better in Ruby than in other languages that
support RTTI / Reflection.

s='abc'
=> "abc"
irb(main):002:0> (s.length -1).downto(0) { |i| p i }
ArgumentError: wrong number of arguments (1 for 0)
from (irb):2:in `length'
from (irb):2
irb(main):003:0> (s.length - 1).downto(0) { |i| p i }
2
1
0
=> 2

At least you got an error.

Cheers,
Joao

 

[Douglas Livingstone]

if this went into ruby,

i'd fork

Alex

if this went into ruby,
i'd download that fork

Douglas

 

[David A. Black]

Hi --

I think that one of the things that make Ruby what it is is the
general flexibility of its syntax. The other day I saw this in an
example for Rails:

{= foo.flash['bar'] if foo.flash['bar'] }

or Something... See? The flexibility paid off for the guy that wanted
to use it like that.

Isn't the idea there to produce a string value if there is one
returned by foo.flash['bar'], but not otherwise? If so, and unless
there's some weird default thing going on, it could be written with
just one foo.flash['bar'] -- which will return nil if not defined,
which is exactly what the unsuccessful 'if' clause will return, and
that nil (either way) will be represented as an empty string. So
while you can use the 'if', there's no gain from doing so in this
case.

(Assuming I'm interpreting the intention correctly, of course.)


David

 

[David A. Black]

Hi --

I agree (with others) that this exact idea isn't so good. Why should you
have to use parens when a method has no args? But the one flaw that has
bothered me about ruby is that _too much_ flexibility in parsing is allowed.
I'd like it if parens were required around a method call's arguments. The
savings in leaving them off i find less than desirable as i (personally)
find it _harder_ to parse things out, visually.

The one I stumble on visually is:

def a b, c, d = e

As for method calls -- I tend to prefer them with parens, but actually
seeing how it plays out in Rails has softened me a little. You get
things like:

class Teacher
has_many :sections
has_one :gradebook

etc., where the non-parens allow for a rather nice-looking
pseudo-config-file look.


David

 

[Joao Pedrosa]

Hi,

Hi --

I think that one of the things that make Ruby what it is is the
general flexibility of its syntax. The other day I saw this in an
example for Rails:

{= foo.flash['bar'] if foo.flash['bar'] }

or Something... See? The flexibility paid off for the guy that wanted
to use it like that.

Isn't the idea there to produce a string value if there is one
returned by foo.flash['bar'], but not otherwise? If so, and unless
there's some weird default thing going on, it could be written with
just one foo.flash['bar'] -- which will return nil if not defined,
which is exactly what the unsuccessful 'if' clause will return, and
that nil (either way) will be represented as an empty string. So
while you can use the 'if', there's no gain from doing so in this
case.

(Assuming I'm interpreting the intention correctly, of course.)

In this case you are right. I probably messed up the example, but with
a more complex "if" it could be handy.

Thanks for clarifying.

Cheers,
Joao

 

[James Britt]

...
As for method calls -- I tend to prefer them with parens, but actually
seeing how it plays out in Rails has softened me a little. You get
things like:

class Teacher
has_many :sections
has_one :gradebook

etc., where the non-parens allow for a rather nice-looking
pseudo-config-file look.

I prefer to avoid parens when it adds to readability by removing
needless reminders that This Is A Computer Language.

I've been using WATIR to create some Web tests for a client, and have
been mucking about creating a DSL such that the average non-programmer
can write a fairly intuitive set of commands without using meaningless
(to them) parens. I'd prefer them not have to think in terms of
arguments and methods, but in simple commands following an intuitive
sequence.


James