Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > mandatory braces

Reply
Thread Tools

mandatory braces

 
 
Johannes Ahl-mann
Guest
Posts: n/a
 
      02-13-2005
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(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
 
Reply With Quote
 
 
 
 
Alexander Kellett
Guest
Posts: n/a
 
      02-13-2005
On Feb 13, 2005, at 3:14 PM, Johannes Ahl-mann wrote:
> please tell me whether this is a bad idea,


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

Alex



 
Reply With Quote
 
 
 
 
David A. Black
Guest
Posts: n/a
 
      02-13-2005
Hi --

On Sun, 13 Feb 2005, 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 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

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

--
David A. Black
http://www.velocityreviews.com/forums/(E-Mail Removed)


 
Reply With Quote
 
Nikolai Weibull
Guest
Posts: n/a
 
      02-13-2005
* Johannes Ahl-mann (Feb 13, 2005 15:20):
> braces (the round ones


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


 
Reply With Quote
 
Bertram Scharpf
Guest
Posts: n/a
 
      02-13-2005
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

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


 
Reply With Quote
 
Nikolai Weibull
Guest
Posts: n/a
 
      02-13-2005
* 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.


,
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);}


 
Reply With Quote
 
craig duncan
Guest
Posts: n/a
 
      02-13-2005
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 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


 
Reply With Quote
 
Joao Pedrosa
Guest
Posts: n/a
 
      02-13-2005
Hi,

On Mon, 14 Feb 2005 07:38:09 +0900, craig duncan
<(E-Mail Removed)> wrote:
> 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 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.

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


 
Reply With Quote
 
Douglas Livingstone
Guest
Posts: n/a
 
      02-14-2005
> if this went into ruby,
> i'd fork
>
> Alex


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

Douglas


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      02-14-2005
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.)


David

--
David A. Black
(E-Mail Removed)


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
the empire braces itself billyw MCSE 17 08-13-2004 11:30 AM
brackets, braces and arrays bric ASP .Net 4 07-05-2004 06:07 PM
AVT / Curly braces : why don't they work for me ? Geathaa XML 1 09-12-2003 01:35 PM
matching curly braces and regular expressions Dustin D. Perl 0 08-26-2003 11:18 PM
Why braces around try/catch? Henrik S. Hansen Java 52 08-22-2003 01:39 AM



Advertisments