[ruby-core:77267] [Ruby trunk Feature#12760] Optional block argument for `itself`

[ruby-core:77267] [Ruby trunk Feature#12760] Optional block argument for `itself`

[zverok.offline]

Issue #12760 has been reported by Victor Shepelev.

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77268] [Ruby trunk Feature#12760] Optional block argument for `itself`

[matthew]

Issue #12760 has been updated by Matthew Kerwin.


[Sounds](https://bugs.ruby-lang.org/issues/6373#note-47) [familiar](https://bugs.ruby-lang.org/issues/10095#note-7), if only someone had submitted a [patch](https://bugs.ruby-lang.org/issues/10095#note-8) or written a [gem](http://www.rubydoc.info/gems/mug/0.5.1/Object%3Aself)  ;)

But yes, once again, I'm +1 for this proposal. Lots of people have objections, though, as you can see particularly in [#10095](https://bugs.ruby-lang.org/issues/10095)

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60499

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77269] [Ruby trunk Feature#12760] Optional block argument for `itself`

[zverok.offline]

Issue #12760 has been updated by Victor Shepelev.


![Okay](https://pbs.twimg.com/profile_images/587051688462135296/vyJ-eDXv.png)

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60500

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77274] [Ruby trunk Feature#12760] Optional block argument for `itself`

[zverok.offline]

Issue #12760 has been updated by Victor Shepelev.


OK, I did not my homework really well this time.
But, to be completely honest, I'm fascinated by how this simple, easy to implement and useful functionality have drowned for ages in "better-name-ever" discussions.

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60504

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77290] [Ruby trunk Feature#12760] Optional block argument for `itself`

[shevegen]

Issue #12760 has been updated by Robert A. Heiler.


> But, to be completely honest, I'm fascinated by how this simple, easy to
> implement and useful functionality have drowned for ages in "better-name-ever"
> discussions.

This is not surprising at all because naming things is one of the hardest
things to get "right".

You just have to look at various rubygems that have a very strange name.

Animal names for instance - a webserver called puma? unicorn as a  HTTP server
for Rack applications?

I can give you another example too, look at some years ago the "File.exist?" 
versus "File.exists?" when both was made available as alias after some people
spoke to matz. I personally don't care much either way since I understand
both points. In "correct" pseudo-english grammar, we can say "does this
file exist?" and "file exists?", but I remember an explanation by apeiros
on IRC once that this would not be the right question asked according to
matz. The question would instead be "object, do you exist?" or "object,
do you contain xyz?". It may be a subtle and minor difference but it sort
of also taps into the philosophy of ruby.

People need or should be vaguely comfortable with syntax. Take the lambda
stabby operator, I can not overcome my mental obstacle to use it - it just
does not "feel right" in my own code. Lots of other people make use of it,
that is fine by me.

Back to the topic of .itself, while I have no strong objection, I struggle
with other method names such as .tap - whenever I read .tap, I actually
think of a certain card game where you have to tap cards. :)

.inject is another odd one, I think of a big nasty syringe (actually my
brain associates it more as name like "sum of", because that is what I
use .inject most regularly like "array.inject(0){|sum,x| sum + x }"
although I suppose there may be another way these days to get the sum
of all integer/float products of an array).

In conclusion, I think you have to expect a certain resistance in particular
for syntax. Best thing is to try to convince matz. And if it won't 
work within ruby 2.x and neither towards the path towards ruby 3.x
and beyond, perhaps it works for ruby 4.x :)

(Actually, perhaps the DSL aspect of ruby could be extended one day
to allow sub-languages of ruby a bit like lisp dialects... but let's
not get too crazy here.)

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60523

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77300] [Ruby trunk Feature#12760] Optional block argument for `itself`

[zverok.offline]

Issue #12760 has been updated by Victor Shepelev.


>> But, to be completely honest, I'm fascinated by how this simple, easy to
implement and useful functionality have drowned for ages in "better-name-ever"
discussions.

> This is not surprising at all because naming things is one of the hardest
things to get "right".

I can understand your point, but sometimes struggle for excellence should just stop to do the real work.

Concept of `.yield_self` (or whatever we name it) method seems like a huge game-changer to me in a challenge of cleaner and idiomatic code. Yes, it's like Elixir's `|>` operator, but it could be introduced in no effort at all.

Does nobody can see it? 
I don't think so, considering how often the question is raised. Four 4 years now (and it is only proposals that are found in tracker)!

OK, let's summarize EVERYTHING that was proposed (and doubted) so far:

* #6721: 
  * `#yield_self`, 
  * `#yield_to`, 
  * `#submit_to`, 
  * `#surrender`, 
  * `#capitulate`, 
  * `#apply`, 
  * `#ergo` (implemented in Ruby Facets exactly like `#itself` proposed here);
  * `#^` (like `four = 2 ^ { |x| x*x }`)
  * `#self` (again, like `#itself` -- yield-or-return-self)
  * `#cast` (more complicated behavior, like `3.cast(2, :+) => 5`)
  * `#toss`
  * `#tap!`
* #7388 (Matz had explicitly stated he is against all of the options)
  * `#embed`
  * `#infix`
  * `#ergo` again
* #6684 (proposal & discussion is partially in Japanese)
  * `#do`
* #11717
  * `#trap` (was my idea, I've liked it to be close to `#tap` yet was pointed to confusion with `Signal#trap`)
* #10095
  * `#as`
  * `#chain`
  * `#self_by`
  * `#revapply`
  * `#block_self`
  * `#itself` (and big discussion why it is **not** appropriate -- don't really persuadive for me, but you can know batter)
  * `#yield`
  * block form of `#send` (like `(2 + 3).send{ |x| x + 2 }`)
  * new method/operator `~>`
  * Using just `|` operator
  * `#continue`

My favourite is, obviously, `itself`, "reading" reasoning could be found above:

> it is not 100% good English, but readable: `itself(&JSON.method(:parse)) = "parse itself with json"`;

But, to be honest, it is not the point. Point is **we need it**, whatever it is called. And except for "new operator" approach, and versions that will confuse parser (`self`, `yield` and `do`), it is really easy to implement after the name was selected.

Please-please-please, could somebody add this topic to next developer's meeting agenda?..

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60537

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77311] [Ruby trunk Feature#12760] Optional block argument for `itself`

[duerst]

Issue #12760 has been updated by Martin Dürst.


Victor Shepelev wrote:

> Please-please-please, could somebody add this topic to next developer's meeting agenda?..

Done, please see https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20161011Japan.

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60551

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77312] [Ruby trunk Feature#12760] Optional block argument for `itself`

[zverok.offline]

Issue #12760 has been updated by Victor Shepelev.


Thanks a lot! (But, sorry for bothering, could it be discussed as "Optional block argument for itself OR another name for `yield self` method"? Like, in hope for final solution, not "optional block argument for itself is rejected, and that's it". List of proposed names I've gathered in current ticket.)

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60552

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77318] [Ruby trunk Feature#12760] Optional block argument for `itself`

[nobu]

Issue #12760 has been updated by Nobuyoshi Nakada.


What about `let` ?:

```ruby
some.long.method.chain.constructing.string
  .let { |s| "(" + s + ")" }
```

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60568

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77567] [Ruby trunk Feature#12760] Optional block argument for `itself`

[shyouhei]

Issue #12760 has been updated by Shyouhei Urabe.


FYI we looked at this issue at developer meeting today.  Because matz was not there this extension still has chance, but the attendees thought `itself`'s block (if any) shall work like how `tap` works.  So it might not be suitable for the requested functionality.

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60838

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77574] [Ruby trunk Feature#12760] Optional block argument for `itself`

[zverok.offline]

Issue #12760 has been updated by Victor Shepelev.


Thanks for the update! Haven't you discussed the probable another name for it?.. We just want it to be in language already.

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-60845

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:77861] [Ruby trunk Feature#12760] Optional block argument for `itself`

[knu]

Issue #12760 has been updated by Akinori MUSHA.


What about giving it an obvious name like `yield_self` and making a syntax sugar `object.{|x| ... }` for calling it like we do in Proc#call?

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-61176

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:78326] [Ruby trunk Feature#12760] Optional block argument for `itself`

[matz]

Issue #12760 has been updated by Yukihiro Matsumoto.


`yield_self` is OK, but I don't think we are going to add `object.{|x| ... }`.

Matz.


----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-61691

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:78331] [Ruby trunk Feature#12760] Optional block argument for `itself`

[zverok.offline]

Issue #12760 has been updated by Victor Shepelev.


Well, I should say `yield_self` is not very readable in context (it raises question which is "self" in that context?):

~~~ruby
construct_url(*params)
  .yield_self(&method(:open))
  .read
  .yield_self(&JSON.method(:parse))
  .to_yaml
  .yield_self {|yml| File.write('cache.yml', yml) }
~~~

But I'd rather prefer to finally have this method in core language, whatever it will be named :)

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-61695

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:79453] [Ruby trunk Feature#12760] Optional block argument for `itself`

[non.dmitriy]

Issue #12760 has been updated by Dmitriy Non.


Hello.
Is there any movement?

----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-62885

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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

[ruby-core:80723] [Ruby trunk Feature#12760] Optional block argument for `itself`

[ko1]

Issue #12760 has been updated by ko1 (Koichi Sasada).


how about `alter`?
at dev meeting, someone said `reform`.


----------------------------------------
Feature #12760: Optional block argument for `itself`
https://bugs.ruby-lang.org/issues/12760#change-64274

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
That's an another attempt to choose good metaphor for `object.(yield self)` (previously: #6721 and ton of duplicates).

In discussion here: https://bugs.ruby-lang.org/issues/11717#note-3 it was said:

> Clearly this is something the Ruby community wants. Just as clearly, it's something nobody can name.

But suddenly... I've thought about this!

```ruby
some.long.method.chain.constructing.string
  .itself { |s| "(" + s + ")" }
  .itself(&method(:puts))

# or
require 'open-uri'

construct_url(*params)
  .itself(&method(:open))
  .read
  .itself(&JSON.method(:parse))
  .to_yaml
  .itself(&File.method(:write))

# NB: I understand that _last_ `itself` in both examples
#     could as well be `tap`. But not all the previous.
```

Pros:

* method is already here, it has pretty name and underused (almost nothing except `group_by(&:itself)` comes to mind);
* it is not 100% good English, but readable: `itself(&JSON.method(:parse))` = "parse itself with json";
* implementation is trivial, no backwards-compatibility issues (like new methods shadowing something important in third-party library) are expected.

Cons:

* ???



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