mandatory braces
Johannes Ahl-mann
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
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
E S
> Aihe: mandatory braces
>
> 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))
Just skipping the method() step might be enough? The visual cue from
a Symbol would seem to be equivalent to parens, so:
function1(function2) # Calls function1 with the result of function2
function1(:function2) # Calls function1 with a Proc/Method object
> - procedure objects could be treated similarly to functions:
> "myproc()" instead of "myproc.call()"
An overridable operator () would be useful.
> - 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,
Well, only for the fact that it would mandate extra typing :)
> Johannes
E
David A. Black
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
dbl...@wobblini.net
Christian Neukirchen
>> - procedure objects could be treated similarly to functions:
>> "myproc()" instead of "myproc.call()"
>
> An overridable operator () would be useful.
I actually would like that, but else, *no way* for forced ().
I think they make python unreadable.
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Nikolai Weibull
> 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);}
Bertram Scharpf
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
Nikolai Weibull
> I'd rather appreciate a way to get rid of the rest of parentheses that
> don't mean expression grouping.
:-D,
craig duncan
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
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
> i'd fork :)
>
> Alex
if this went into ruby,
i'd download that fork :)
Douglas
David A. Black
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 A. Black
On Mon, 14 Feb 2005, craig duncan wrote:
> 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.
Joao Pedrosa
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