I don’t think it’s pretty, either. But you seem very keen on
destroying this proposal
I’ve been using Ruby for a long time, and I can count on my two hands
the number of times I’ve placed a begin inside a block. This makes
my highly skeptical of your need for it.
If you read through the mailing list you’ll find all syntax change
proposals meet this kind of treatment.
– you say you need a way to add rescue clauses to curly bracket
blocks, and when I present one, you just dismiss it.
Probably because we don’t think it is rubyish. Note that this has
been proposed before and nobody’s come up with a good-enough solution
yet.
Here’s what I see as the problems with your proposal:
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.
–
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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.
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.
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)
|> For the record, there’s another difference: you cannot use do/end with
|> BEGIN/END.
|
|I never knew that. Is there an obvious reason I’m not seeing?
Since it’s from AWK, I honored the AWK syntax, and saw no need to
support do…end. Consistency? Nah.
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.
Do we really need to allow rescue clauses
on curly bracket blocks?
Yes.
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.