better yet with a lookup table. This sort of problem is handled easily
by intelligent data-driven design.
Don’t mix system design with language capabilities please.
I’m not. This proposal does. What you’re wanting to do is effectively make
it so that case operates in parallel on multiple conditions. I can count on
zero hands the number of times that I’ve needed this capability. I have
found it more useful to worry about my data design and make sure that I
have a proper lookup table. Robert’s design does exactly that with multiple
custom objects instead of a lookup table.
I think it’s not a bad thing to let “case” to take more than one
expressions. Just like a function can take any number of arguments. Why
does “case” have to be limited to zero or one? Because all our languages
are designed this way? (AFAIK only Ruby “case” can take 0 expressions.
That’s some good stuff introduced by Ruby, right? So why not go one step
further?) Or because it’s impossible?
Nothing is impossible. It’s a question as to whether it’s a good idea.
Frankly, your proposal is a bad idea. I said as much to your initial posting
on RubyGarden.
There is no need for a new or modified language construct here.
Since 2.0 is a major update to 1.x, why can’t we introduce new language
constructs if they really makes sense?
Except that your construct doesn’t make sense.
- It introduces unnecessary complexity.
- It adds a lot of “magic” that isn’t clear (_ or ~ – both are really
ugly). Ruby2 seems to be getting rid of a lot of that silly magic. - It adds a language “feature” that is better handled by proper program
design.
-austin