Ruby suggestion feedback


#1

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


#2

Hi –

On Sat, 7 Jul 2007, Roger P. wrote:

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


#3

Here’s another thought. Who would vote for this?
“rescue => detail” catching Exception by default

unknown wrote:

Hi –

On Sat, 7 Jul 2007, Roger P. wrote:

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


#4

Roger P. wrote:

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


#5

On 7/18/07, Roger P. removed_email_address@domain.invalid wrote:

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 :wink: but David is right, this is
about to be addressed already…

Cheers
Robert


#6

Stefan R. wrote:

Roger P. wrote:

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

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


#7

On Thu, 19 Jul 2007 04:31:33 +0900, Stefan R. wrote:

Roger P. wrote:

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.

Probably under the influence of Java.

–Ken