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
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
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
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
On 7/18/07, Roger P. [email protected] 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 
but David is right, this is
about to be addressed already…
Cheers
Robert
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.
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