[#85940] [Ruby trunk Bug#14578] Forking a child process inside of a mutex crashes the ruby interpreter — ben.govero@...
Issue #14578 has been reported by bengovero (Ben Govero).
3 messages
2018/03/05
[#86205] [Ruby trunk Feature#14618] Add display width method to String for CLI — aycabta@...
Issue #14618 has been reported by aycabta (aycabta .).
3 messages
2018/03/19
[#86366] Re: [ruby-cvs:70102] usa:r63008 (trunk): get rid of test error/failure on Windows introduced at r62955 — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/03/28
[ruby-core:86068] [Ruby trunk Feature#14594] Rethink yield_self's name
From:
shevegen@...
Date:
2018-03-09 13:50:30 UTC
List:
ruby-core #86068
Issue #14594 has been updated by shevegen (Robert A. Heiler).
I agree. Though I have to admit that I never used yield_self
so far. I can not even say what it does, either. :)
I like yield and self. I don't like the name yield_self.
> After reconsidering a lot of options, my current
> proposal is: #then.
I dislike that as well. I also do not think that "then"
makes a lot of sense.
For example:
File.read(filename).then(&JSON.method(:parse))
This is regular method chaining. But it sounds like
you are using a conditional there.
"then" is already a keyword in ruby isn't it?
https://docs.ruby-lang.org/en/2.5.0/keywords_rdoc.html
> In many languages, .then or .and_then is useful construct, meaning
> the same (calculate next value from the result of the previous
> operation), just in a narrower context of futures/promises.
Realistically ruby should strive for intrinsic consistency first,
not for what features or anti-features other languages may or
may not have.
> I believe that even when/if Ruby will have those as a
> language feature, that syntax will play well:
value.then(&:computation) # => value
promise.then(&:computation) # => promise
I don't think it reads nicely really.
yield_self is not a good name but your proposal is also
not good, in my opinion. But it's just a personal opinion,
feel free to ignore it. At the end of the day you only have
to convince matz. :)
The name yield_self is however had indeed not a good name.
Finding good names is quite difficult. Single words are
also almost always better than combined names, even though
one is a bit limited with single words alone. There are
exceptions though. For example **.each_with_index** or
**.each_index** are good names, IMO.
----------------------------------------
Feature #14594: Rethink yield_self's name
https://bugs.ruby-lang.org/issues/14594#change-70932
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
*I feel really uncomfortable raising the question again, but...*
In several months since 2.5 release I've written a lot of code with `yield_self` (using `backports` gem with earlier versions of Ruby when necessary), and explained it several times to students, and colleagues (and in this [blog post](https://zverok.github.io/blog/2018-01-24-yield_self.html) which have gained pretty decent attention).
I should say that I am still assured the name chosen is really not optimal. Reasons:
* it is just too long for such a basic operation;
* it does not say "what it does", but rather "how it is implemented"; it is like having `each_returning_block_result` instead of `map`;
* `self` is really misguiding and obscure in situations like this:
```ruby
class MyClass
def some_method
@path.yield_self(&File.method(:read)).yield_self(&Parser.method(:new)) ...
end
end
```
Intuitively, word "self" inside instance method is read like it somehow related to current context's `self` (e.g. instance of `MyClass`), which it is absolutely not. In other words, "self" in caller's context has nothing to do with "self" implied by method's name.
After reconsidering a lot of options, **my current proposal is: `#then`**.
Reasons:
* despite being a keyword, `something.then(something)` is not a conflicting Ruby syntax, and allowed by current Ruby;
* it is short!
* it shows intention pretty well, and reads natural, in both cases: when receives block and when returns Enumerator:
```ruby
File.read(filename).then(&JSON.method(:parse))
rand(10).then.detect(&:odd?)
```
In many languages, `.then` or `.and_then` is useful construct, meaning the same (calculate next value from the result of the previous operation), just in a narrower context of futures/promises. I believe that even when/if Ruby will have those as a language feature, that syntax will play well:
```ruby
value.then(&:computation) # => value
promise.then(&:computation) # => promise
```
PS: For historical reasons, [here](https://bugs.ruby-lang.org/issues/12760#note-5) is huge list of previous proposals I've gathered for this method name.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
