[#84867] [Ruby trunk Bug#14357] thread_safe tests suite segfaults — v.ondruch@...
Issue #14357 has been reported by vo.x (Vit Ondruch).
11 messages
2018/01/15
[#85364] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
v.ondruch@tiscali.cz wrote:
[#85368] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
Eric Wong wrote:
[#85442] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/06
Eric Wong <normalperson@yhbt.net> wrote:
[#85451] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Vladimir Makarov <vmakarov@...>
2018/02/06
On 02/06/2018 05:00 AM, Eric Wong wrote:
[#85455] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/06
Vladimir Makarov <vmakarov@redhat.com> wrote:
[#84874] [Ruby trunk Bug#14360] Regression CSV#open method for writing from Ruby 2.4.3 to 2.5.0 — shevegen@...
Issue #14360 has been updated by shevegen (Robert A. Heiler).
3 messages
2018/01/15
[#84980] [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — hsbt@...
Issue #13618 has been updated by hsbt (Hiroshi SHIBATA).
10 messages
2018/01/23
[#85012] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/23
hsbt@ruby-lang.org wrote:
[#85081] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
Eric Wong <normalperson@yhbt.net> wrote:
[#85082] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
> Thinking about this even more; I don't think it's possible to
[#85088] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — danieldasilvaferreira@...
Issue #13618 has been updated by dsferreira (Daniel Ferreira).
3 messages
2018/01/25
[#85107] [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is? — eregontp@...
Issue #14222 has been updated by Eregon (Benoit Daloze).
3 messages
2018/01/25
[#85136] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — Eric Wong <normalperson@...>
samuel@oriontransfer.org wrote:
3 messages
2018/01/26
[ruby-core:84783] [Ruby trunk Feature#14344] refine at class level
From:
zverok.offline@...
Date:
2018-01-09 17:31:08 UTC
List:
ruby-core #84783
Issue #14344 has been updated by zverok (Victor Shepelev).
> Also I guess in general refinements are not defined right in the class using them, especially if they are not trivial one-liner methods.
I believe that "one-liner" & "inplace" definition is one of the most important usages of refinements.
Because, speaking philosophically, why do we need them at all?
Instead of doing "`refine String` + call `string.something`" you always can `StringUtilModule.something(string)`, but when you do some, say, complicated reporting algorithm, those `StringUtilModule.something(string)`, especially several in a row can become REALLY ugly.
Therefore you just... add one small method to `String`. Just here and there, as close to its usage and as visible and as easy as possible, and it WILL be one-line method, just calling the same `StringUtilModule.something(string)` (which is easier to test and maintain and document).
I believe that "module with refinement for the several classes" is, to the opposite, much less frequent case. It is either "all cool shticks for my entire project in one file", or something very domain-specific (like, I don't know, `String#as_currency`, `Numeric#as_money(currency)`, `CSV#ready_money` something).
----------------------------------------
Feature #14344: refine at class level
https://bugs.ruby-lang.org/issues/14344#change-69499
* Author: kddeisz (Kevin Deisz)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
I rely on refinements a lot, but don't want to keep writing `Module.new` in code. I'm proposing `Object::refine`, which would create an anonymous module behind the scenes with equivalent functionality. So:
~~~ ruby
class Test
using Module.new {
refine String do
def refined?
true
end
end
}
end
~~~
would become
~~~ ruby
class Test
refine String do
def refined?
true
end
end
end
~~~
It's a small change, but reads a lot more clearly. Thoughts?
--
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>