[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...
Issue #14723 has been updated by ko1 (Koichi Sasada).
13 messages
2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
ko1@atdot.net wrote:
[#86791] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:18, Eric Wong wrote:
[#86792] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86793] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:47, Eric Wong wrote:
[#86794] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86814] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
[#86815] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/02
Koichi Sasada <ko1@atdot.net> wrote:
[#86816] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
On 2018/05/02 11:49, Eric Wong wrote:
[#86847] [Ruby trunk Bug#14732] CGI.unescape returns different instance between Ruby 2.3 and 2.4 — me@...
Issue #14732 has been reported by jnchito (Junichi Ito).
3 messages
2018/05/02
[#86860] [Ruby trunk Feature#14723] [WIP] sleepy GC — sam.saffron@...
Issue #14723 has been updated by sam.saffron (Sam Saffron).
6 messages
2018/05/03
[#86862] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/03
sam.saffron@gmail.com wrote:
[#86935] [Ruby trunk Bug#14742] Deadlock when autoloading different constants in the same file from multiple threads — elkenny@...
Issue #14742 has been reported by eugeneius (Eugene Kenny).
5 messages
2018/05/08
[#87030] [Ruby trunk Feature#14757] [PATCH] thread_pthread.c: enable thread caceh by default — normalperson@...
Issue #14757 has been reported by normalperson (Eric Wong).
4 messages
2018/05/15
[#87093] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
3 messages
2018/05/17
[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
9 messages
2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/17
ko1@atdot.net wrote:
[#87166] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/18
Eric Wong <normalperson@yhbt.net> wrote:
[#87486] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/06/13
I wrote:
[ruby-core:87319] [Ruby trunk Feature#14594] Rethink yield_self's name
From:
jonathan@...
Date:
2018-05-31 13:01:02 UTC
List:
ruby-core #87319
Issue #14594 has been updated by jrochkind (jonathan rochkind).
I'm concerned that `then` is used in Promises, and is already in use in many promise-implementing libraries, including [concurrent-ruby](http://ruby-concurrency.github.io/concurrent-ruby/Concurrent/Promise.html).
The Promise libraries could change the name of their method to not conflict, but then it's not only backwards compatibility but a mis-match with Promises in other platforms, and the original JS spec that they are based on.
The Promise libraries can keep doing this, effectively overriding the Kernel method. Somewhat confusingly `then` will mean something different when used on a Promise object, and Kernel#then won't be available on them. I guess since it's just an alias, this isn't a disaster, yield_self is still available, but if you're using Promises you've got to think about what kind of object you have and which alias you want, and that `then` means something different on Promises.
----------------------------------------
Feature #14594: Rethink yield_self's name
https://bugs.ruby-lang.org/issues/14594#change-72312
* Author: zverok (Victor Shepelev)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* 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:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>