[#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:87195] [Ruby trunk Feature#14249] Remove str[match_str]
From:
shevegen@...
Date:
2018-05-19 18:13:37 UTC
List:
ruby-core #87195
Issue #14249 has been updated by shevegen (Robert A. Heiler).
As Kentaro showed, there are use cases for [], as-in replacement.
It is quite concise so I think it may be useful for some ruby hackers.
I personally use the more verbose variants usually; as Benoit showed,
".include?" checks, and then often .tr() or .sub() or .gsub(). It
is not as concise as Kentaro's example, but I like working with
.sub() and .gsub() and .include?() so I tend to use them when possible.
I also use Regexes a lot; they are extremely useful.
Of course in the above, a regex can be used and I think there is more
ruby code that uses regexes instead:
s[/age/] = "heese"
I don't know offhand about differences as hanmac stated, but I personally
use regexes almost always, so the // syntax. But Yuki also mentioned a
difference, e. g. the String having to become a regex (and I remember
in the old pickaxe, that creating a regex is more costly than creating
a String).
Since some time we can use regexes for .start_with?() and .end_with?()
checks; before that, I think we could use only Strings.
In .include?() checks, we seem to be only able to use Strings. Would
adding regex support there be good? I don't want to distract from the
issue here, so I am just mentioning it.
Anyway, Ana wrote:
> the question is if it makes sense to keep str[match_str]. It is a
> confusing method...
I don't really think it is a confusing method - it seems very simple
to me. I don't use it myself because of alternatives, but I think
trying to want to make ruby "perfect" in every theoretical aspect,
is very, very difficult, even without backwards compatibility.
Ruby is a great language but that does not necessarily mean that 100%
of ruby is perfect (or great). Ruby hackers have to decide on what
they want to write, how to write it and so forth.
What works in my case is to focus (and use) what I like in ruby and
mostly ignore the rest. (I am not speaking about string[match_string]
but e. g. @@class_variables as example; I realized one day that I do
not need it, so I stopped using them and everything is fine).
Perhaps that also works for your use cases when writing ruby code Ana.
----------------------------------------
Feature #14249: Remove str[match_str]
https://bugs.ruby-lang.org/issues/14249#change-72184
* Author: ana06 (Ana Maria Martinez Gomez)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
I wonder if `str[match_str]` makes sense.
``` Ruby
"ana"['a'] => "a"
```
I would say this is not expected and it brings problems, for example when accessing nested hashes. For example:
``` Ruby
params = { "user" => "Nicolas Cage" } => {"user"=>"Nicolas Cage"}
params["user"]["age"] => "age"
```
I think `str[regexp]` is enough and that `str[match_str]` can be removed.
--
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>