mandatory braces

Discussion in 'Ruby' started by Johannes Ahl-mann, Feb 13, 2005.

  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 ;-) 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
     
    Johannes Ahl-mann, Feb 13, 2005
    #1
    1. Advertising

  2. 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
     
    Alexander Kellett, Feb 13, 2005
    #2
    1. Advertising

  3. 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
     
    David A. Black, Feb 13, 2005
    #3
  4. * 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);}
     
    Nikolai Weibull, Feb 13, 2005
    #4
  5. 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
     
    Bertram Scharpf, Feb 13, 2005
    #5
  6. * 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);}
     
    Nikolai Weibull, Feb 13, 2005
    #6
  7. Johannes Ahl-mann

    craig duncan Guest

    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
     
    craig duncan, Feb 13, 2005
    #7
  8. Johannes Ahl-mann

    Joao Pedrosa Guest

    Hi,

    On Mon, 14 Feb 2005 07:38:09 +0900, craig duncan
    <> 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
     
    Joao Pedrosa, Feb 13, 2005
    #8
  9. > if this went into ruby,
    > i'd fork :)
    >
    > Alex


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

    Douglas
     
    Douglas Livingstone, Feb 14, 2005
    #9
  10. 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
     
    David A. Black, Feb 14, 2005
    #10
  11. Hi --

    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.


    David

    --
    David A. Black
     
    David A. Black, Feb 14, 2005
    #11
  12. Johannes Ahl-mann

    Joao Pedrosa Guest

    Hi,

    On Mon, 14 Feb 2005 09:11:34 +0900, David A. Black <> 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. :)

    Thanks for clarifying.

    Cheers,
    Joao
     
    Joao Pedrosa, Feb 14, 2005
    #12
  13. Johannes Ahl-mann

    James Britt Guest

    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
     
    James Britt, Feb 14, 2005
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. valentin tihomirov

    mandatory output binding?

    valentin tihomirov, Jul 2, 2005, in forum: VHDL
    Replies:
    1
    Views:
    504
    Jonathan Bromley
    Jul 4, 2005
  2. Srinivas

    mandatory text fields

    Srinivas, Mar 22, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    509
    Karl Seguin
    Mar 22, 2005
  3. Pete Barrett
    Replies:
    0
    Views:
    572
    Pete Barrett
    Jun 8, 2005
  4. Chris West

    XSD mandatory element

    Chris West, Jun 27, 2003, in forum: XML
    Replies:
    1
    Views:
    6,024
    Colin Mackenzie
    Jun 27, 2003
  5. Piers Chivers
    Replies:
    2
    Views:
    414
    Piers Chivers
    Mar 2, 2004
Loading...

Share This Page