I don't think it's pretty, either. But you seem very keen on destroying
this proposal -- you say you need a way to add rescue clauses to curly
bracket blocks, and when I present one, you just dismiss it.
I'd like you to be more constructive here.
1. Do we *really* need to allow rescue clauses
on curly bracket blocks?
Yes.
2. If yes, what syntax would you propose?
foo { bar rescue baz }
or
foo {
bar
rescue
baz
}
Personally, I don't think we need it. Curly brackets don't look like
begin/end, class/end, or def/end at all; do/end does. I've tried adding
a rescue clause to a do/end block, expecting it to work, I've never done
that with curly brackets blocks.
If we're going to have it in do/end blocks, we need it in blocks. Period.
-austin
···
On 5/19/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
No, ruby itself directly contradicts you. The language defines only one difference between {/} and do/end, precedence. Increasing the differences will make ruby more about the computer than the programmer because you must remember what to put where to please the interpreter. Adding syntax is usually makes the language more complicated and that can only be bad.
···
On May 18, 2006, at 3:32 PM, Daniel Schierbeck wrote:
Eric Hodel wrote:
On May 18, 2006, at 2:24 PM, Daniel Schierbeck wrote:
dblack@wobblini.net wrote:
I'm not sure I get that distinction -- I mean, I understand that you
do it that way, but I'm not sure there's any generally closer
association between do/end and rescuing than there is between {} and
rescuing. Also, they're sometimes used in the *same* places, but by
different people
Maybe it's time we make that distinction. From a syntactical point of view, they're very different
parse.y disagrees with you.
That's implementation. We ought to be able to abstract away from that, right? Isn't Ruby about the programmer, not the computer?
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Yes, but as I said -- and I know you haven't seen it as I'm writing it
-- Ruby treats them exactly the same except for precedence. I like it
that way, personally.
-austin
···
On 5/18/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:
Eric Hodel wrote:
> On May 18, 2006, at 2:24 PM, Daniel Schierbeck wrote:
>
>> dblack@wobblini.net wrote:
>>> I'm not sure I get that distinction -- I mean, I understand that you
>>> do it that way, but I'm not sure there's any generally closer
>>> association between do/end and rescuing than there is between {} and
>>> rescuing. Also, they're sometimes used in the *same* places, but by
>>> different people
>> Maybe it's time we make that distinction. From a syntactical point of
>> view, they're very different
> parse.y disagrees with you.
That's implementation. We ought to be able to abstract away from that,
right? Isn't Ruby about the programmer, not the computer?
You omitted how you would specify which exceptions would be rescued.
} else { would be very confusing.
Your current solution looks entirely unlike ruby's current exception catching syntax.
Your current solution looks entirely unlike any current ruby code.
So you agree that there's no way in hell a Ruby programmer would never try to add exception handling to curly bracket blocks? Then why oh why must we support it? Why not just add exception handling capabilities to do/end blocks, period -- that's where it feels natural to add rescue clauses, anyway.
If it's possible to add clauses to do/end blocks and not {} blocks, I don't see a problem at all.
You omitted how you would specify which exceptions would be rescued.
} else { would be very confusing.
Your current solution looks entirely unlike ruby's current exception catching syntax.
Your current solution looks entirely unlike any current ruby code.
So you agree that there's no way in hell a Ruby programmer would never try to add exception handling to curly bracket blocks? Then why oh why must we support it?
Are you deliberately misunderstanding? The only agreement I saw is
that this is ugly.
Why not just add exception handling capabilities to do/end blocks, period -- that's where it feels natural to add rescue clauses, anyway.
If it's possible to add clauses to do/end blocks and not {} blocks, I don't see a problem at all.
That would be yet another difference between do/end and {}.
Right now, precedence is the only difference. It works well.
If we added it to do/end, we'd have to add it to {}. But heavens,
not using the insane syntax in your last message. Better to leave
it alone.
Furthermore, I question the need for this feature in the first place.
Well BEGIN and END almost seem like they should be control structures to me anyway. (Esepecially since the { } following BEGIN and END aren't blocks (in the sense of being yield-able or convertable to a proc)
