From: shevegen@...
Date: 2019-12-21T16:12:50+00:00
Subject: [ruby-core:96391] [Ruby master Feature#16441]	Enumerable#take_while_after

Issue #16441 has been updated by shevegen (Robert A. Heiler).


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", I think
the shorter the method name, the better (usually that is).

So we have methods such as:

    .size
    .keys
    .uniq

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 - which I mean in general, primarily, not solely confined
to the name here.

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.


----------------------------------------
Feature #16441: Enumerable#take_while_after
https://bugs.ruby-lang.org/issues/16441#change-83314

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
The method is just like `#take_while`, but also includes the item where condition became true.

Examples of usefulness:
```ruby
str = <<DOC
prologue
<<
1
2
3
>>
epilogue
DOC
# Imagine we want to take everything starting from << to >> in short and clean Ruby
# Surprisingly, our best guess would be infamous flip-flop:
p str.each_line(chomp: true).filter_map { _1 if _1 == '<<'.._1 == '>>' }
# => ["<<", "1", "2", "3", ">>"]

# Trying to achieve this with Enumerator, you _almost_ can express it, but...
p str.each_line(chomp: true).drop_while { _1 != '<<' }.take_while { _1 != '>>' }
# => ["<<", "1", "2", "3"] -- the last line is lost.

# So, Enumerable leaves us with this (which is harder to read, due to additional `.first`):
p str.each_line(chomp: true).drop_while { _1 != '<<' }.slice_after { _1 == '>>' }.first
# => ["<<", "1", "2", "3", ">>"]

# With proposed method:
p str.each_line(chomp: true).drop_while { _1 != '<<' }.take_while_after { _1 != '>>' }
# => ["<<", "1", "2", "3", ">>"]
```

The idea is the same as with flip-flops `..` vs `...` (sometimes we need to include the last element matching the condition, sometimes don't), and `while ... end` vs `do ... while`. Another example (from `Enumerator.produce` [proposal](https://bugs.ruby-lang.org/issues/14781)):

```ruby
require 'strscan'
scanner = StringScanner.new('7+38/6')
p Enumerator.produce { scanner.scan(%r{\d+|[-+*/]}) }.take_while { !scanner.eos? } # expresses meaning, but loses last element
# => ["7", "+", "38", "/"]
p Enumerator.generate { scanner.scan(%r{\d+|[-+*/]}) }.slice_after { scanner.eos? }.first # slice_after {}.first again
# => ["7", "+", "38", "/", "6"]
p Enumerator.produce { scanner.scan(%r{\d+|[-+*/]}) }.take_while_after { !scanner.eos? }
# => ["7", "+", "38", "/", "6"]
```

PS: Not sure about the name, suggestions are welcome



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>