Mandatory braces

ruby-talk
1

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 :wink: 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(method(:function2))
- 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

2

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

Alex

路路路

On Feb 13, 2005, at 3:14 PM, Johannes Ahl-mann wrote:

please tell me whether this is a bad idea,

3

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 :wink: 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(method(:function2))
- 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 :slight_smile:

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

David

路路路

On Sun, 13 Feb 2005, Johannes Ahl-mann wrote:

--
David A. Black
dblack@wobblini.net

4

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

braces (the round ones :wink:

Parentheses, please,
  nikolai

路路路

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

5

Hi,

路路路

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

if ruby made braces (the round ones :wink: 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

--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

6

Johannes Ahl-mann wrote:

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 :wink: 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(method(:function2))
- 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

7

* 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

路路路

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

8

Hi,

Johannes Ahl-mann wrote:
> 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 :wink: 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(method(:function2))
> - 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:

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. :slight_smile:

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. :slight_smile:

Cheers,
Joao

路路路

On Mon, 14 Feb 2005 07:38:09 +0900, craig duncan <craig-duncan@earthlink.net> wrote:

9

if this went into ruby,
i'd fork :slight_smile:

Alex

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

Douglas

10

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

路路路

On Mon, 14 Feb 2005, craig duncan wrote:

--
David A. Black
dblack@wobblini.net

11

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

路路路

On Mon, 14 Feb 2005, Joao Pedrosa wrote:

--
David A. Black
dblack@wobblini.net

12

David A. Black wrote:
> ...

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

13

Hi,

路路路

On Mon, 14 Feb 2005 09:11:34 +0900, David A. Black <dblack@wobblini.net> wrote:

Hi --

On Mon, 14 Feb 2005, Joao Pedrosa wrote:

> 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. :slight_smile:

Thanks for clarifying.

Cheers,
Joao