This is of course only my personal opinion, but I believe that long
names can be somewhat problematic. Now I myself use really very
long method names, but for ruby as a "basic building block" (that
is the core parts), I think the shorter the method name, the better
(usually that is).
So we have methods such as:
.size
.keys
.uniq
Short and expressive.
And we have some methods with two words:
.each_pair
.take_while
And so forth.
I believe that the net benefit of methods becomes lesser the more words
have to be used for a particular method call - which I mean in general,
primarily, not solely confined to the name/issue here. Like, three
words, or four words, or five words ... or things such as
HashWithIndirectAccess.
I think three words are quite unwieldy. It also feels a bit strange since
this is almost as if you could do a method-chain, like:
.take_while_after
.take.while.after
Reminds me a bit of rspec.
Of course it depends a lot on how someone uses ruby, which "style" is to
be preferred, but for me personally, I much prefer the shorter, simpler
variant whenever that would be possible. It is a bit comparable to
"yield_self" versus "then" - if the question is solely between these two
names, then the name "then" is IMO better, because it is easier to use.
I don't have a good alternative name either, but I am also not sure if there
can be a much simpler name IF the thought behind the suggestion is to
combine so many different method calls in one go.
Perhaps we could have two variants of ruby, one for the simple minds, and
one for the uber gurus that may find haskell too easy. ;-)
The idea is the same as with flip-flops .. vs ...
Well, the difference here is a single (!) character.
I think you are a bit afar from that difference. I also already find
.take_while a peculiar name ...
By the way, another small point to note is that in the method chain,
"while" appears twice. That seems a bit odd to me too.