I'm not drawn to this. It's a bit to much of a special or particular usage case getting its own syntax, which is a never-ending road down which I prefer Ruby to go as little as possible. The syntactic building blocks are already awfully concise.
It's also not clear why collect gets to be the default here. One might also concat the results of a select or reject operation -- and then one would fall back on:
a.concat(b.select {|e| e > 1}) # or whatever
To save typing 'collect' (or 'map' :-) by making a special default collect case where the block comes after the parens doesn't strike me as worthwhile. Also, consider that you'd still have to do:
a.concat(b.collect! {|e| e *2 })
i.e., the bang case, explicitly. I'd rather not have one more special case to learn (and have to explain).
Whoops, I forgot to sign my comment: -- David Black
Hmm. I don't think the in place variation is signifficant, but I do see your point with #select --that is a viable alternative. But I disagree that it is a never-ending road down a special or particular usage case. It's just a choice between a few viable general usage cases.
There is a philosophical divide here. Do we "fill-up" the capabilities of methods where viable, or not? In other words, in this case, since concat doesn't have any current use for a block, isn't it better that it do something rather then nothing --even if we must pick one of a number of alternative functionings?
These issue are also not not an all or nothing choice. I just tend to _lean_ toward filler-up. Mostly b/c the alternative lead to many additional method definitions (and calls) --and Ruby is slow on method lookup.
I wish I could edit my comment :(. Oh well. -T.
I think it breaks modularization, assuming that concat is going to be used after filtering some items. I don't like that.
Mariano Montone
It's also not clear why collect gets to be the default here. One might also concat the results of a select or reject operation -- and then one would fall back on:
a.concat(b.select {|e| e > 1}) # or whateverTo save typing 'collect' (or 'map' :-) by making a special default collect case where the block comes after the parens doesn't strike me as worthwhile. Also, consider that you'd still have to do:
a.concat(b.collect! {|e| e *2 })i.e., the bang case, explicitly. I'd rather not have one more special case to learn (and have to explain).
Whoops, I forgot to sign my comment: -- David Black
Hmm. I don't think the in place variation is signifficant, but I do see your point with #select --that is a viable alternative. But I disagree that it is a never-ending road down a special or particular usage case. It's just a choice between a few viable general usage cases.
There is a philosophical divide here. Do we "fill-up" the capabilities of methods where viable, or not? In other words, in this case, since concat doesn't have any current use for a block, isn't it better that it do something rather then nothing --even if we must pick one of a number of alternative functionings?
These issue are also not not an all or nothing choice. I just tend to _lean_ toward filler-up. Mostly b/c the alternative lead to many additional method definitions (and calls) --and Ruby is slow on method lookup.
I wish I could edit my comment :(. Oh well. -T.
I think it breaks modularization, assuming that concat is going to be used after filtering some items. I don't like that.