ruby suggestion feedback

[Roger Pack]

Hmm. I realize these have been discussed before, but... (terrible way to
start a post, I know).
I for one, being the terrible newbie I am, would like to suggest the
following change to Ruby (like RCR it).
Variable parameter assignment in function calls. (sorry)
i.e. the following:
function_x(3,4,failure=true,options=false)

(by default, not using hashes). This allows for more understandable
code than
function_x(3,4,true,true,1,true,false) # does anyone after 3 months
remember what each of those MEANT? [note the true,false at the
end--those were my "failure" and "options," from the first example].
I'm not saying Ruby is bad, just that this would be better.

Any thoughts? Should I RCR it?

Thanks!
-Roger

 

[dblack]

Hi --

Hmm. I realize these have been discussed before, but... (terrible way to
start a post, I know).
I for one, being the terrible newbie I am, would like to suggest the
following change to Ruby (like RCR it).
Variable parameter assignment in function calls. (sorry)
i.e. the following:
function_x(3,4,failure=true,options=false)

(by default, not using hashes). This allows for more understandable
code than
function_x(3,4,true,true,1,true,false) # does anyone after 3 months
remember what each of those MEANT? [note the true,false at the
end--those were my "failure" and "options," from the first example].
I'm not saying Ruby is bad, just that this would be better.

Any thoughts? Should I RCR it?

All this stuff (argument syntax and semantics, keyword arguments,
etc.) is very much on the radar already. I don't think there's
anything to be gained by submitting an RCR for one particular version
of it. In 1.9 you've got hash shortcuts and possibly other things
already coming:

x(failure: true, options: false, ...)

(May not be a working example but that's the kind of thing.)


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Phrogz]

Variable parameter assignment in function calls. (sorry)
i.e. the following:
function_x(3,4,failure=true,options=false)

(by default, not using hashes). This allows for more understandable
code than
function_x(3,4,true,true,1,true,false) # does anyone after 3 months
remember what each of those MEANT? [note the true,false at the
end--those were my "failure" and "options," from the first example].

I suspect you really mean named paramaters allowed in such a way that
you don't have to remember the order of parameters when calling the
method. However, I wanted to point out that what you wrote is legal,
and does address one of your points:

Slim2:~ phrogz$ irb
irb(main):001:0> def do_it( times=3, failure=true, options=false )
irb(main):002:1> p times, failure, options
irb(main):003:1> end
=> nil

irb(main):004:0> do_it( times=12, failure=false, options=false )
12
false
false
=> nil

You still need to pass the parameters in the correct order, but when
invoking the method there's nothing preventing you from assigning the
values to (dummy) local variables in the process as nice labels for
someone reading the code later.

 

[Roger Pack]

Here's another thought. Who would vote for this?
"rescue => detail" catching Exception by default

Hi --

function_x(3,4,true,true,1,true,false) # does anyone after 3 months
remember what each of those MEANT? [note the true,false at the
end--those were my "failure" and "options," from the first example].
I'm not saying Ruby is bad, just that this would be better.

Any thoughts? Should I RCR it?

All this stuff (argument syntax and semantics, keyword arguments,
etc.) is very much on the radar already. I don't think there's
anything to be gained by submitting an RCR for one particular version
of it. In 1.9 you've got hash shortcuts and possibly other things
already coming:

x(failure: true, options: false, ...)

(May not be a working example but that's the kind of thing.)


David

 

[Stefan Rusterholz]

Here's another thought. Who would vote for this?
"rescue => detail" catching Exception by default

I wouldn't. The current behaviour is good.
Sadly though there are some library writers out there inheriting from
Exception instead of StandardError for non-fatal stuff.

Regards
Stefan

 

[Robert Dober]

Here's another thought. Who would vote for this?
"rescue => detail" catching Exception by default

Oh no, it might be a good feature I dunno, but it would be terribly abused...
I do not see any obvious advantage that would justify that risk.

For what concerns your first suggestion it is a good one, Bravo for a
newbie ( you might come from Python but David is right, this is
about to be addressed already....

Cheers
Robert

 

[Ken Bloom]

I wouldn't. The current behaviour is good. Sadly though there are some
library writers out there inheriting from Exception instead of
StandardError for non-fatal stuff.

Probably under the influence of Java.

--Ken

 

[Roger Pack]

I wouldn't. The current behaviour is good.
Sadly though there are some library writers out there inheriting from
Exception instead of StandardError for non-fatal stuff.

Regards
Stefan

Yeah it just gets me that things like Timeout::Error does not inherit
from StandardError. I agree.