[#83096] File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?}) — Nobuyoshi Nakada <nobu@...>
On 2017/10/04 8:47, normal@ruby-lang.org wrote:
5 messages
2017/10/04
[#83100] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Eric Wong <normalperson@...>
2017/10/04
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#83105] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Nobuyoshi Nakada <nobu@...>
2017/10/04
On 2017/10/04 15:55, Eric Wong wrote:
[#83107] Alias Enumerable#include? to Enumerable#includes? — Alberto Almagro <albertoalmagro@...>
Hello,
9 messages
2017/10/04
[#83113] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/05
This has been requested countless times, then rejected each and every time.
[#83129] Re: Alias Enumerable#include? to Enumerable#includes?
— Alberto Almagro <albertoalmagro@...>
2017/10/05
Sorry I didn't found it on the core mail list's archive.
[#83138] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/06
Ruby has not been made of popular votes so far. You have to show us
[#83149] Re: Alias Enumerable#include? to Enumerable#includes?
— Eric Wong <normalperson@...>
2017/10/06
Alberto Almagro <albertoalmagro@gmail.com> wrote:
[#83200] [Ruby trunk Feature#13996] [PATCH] file.c: apply2files releases GVL — normalperson@...
Issue #13996 has been reported by normalperson (Eric Wong).
4 messages
2017/10/10
[ruby-core:83482] [Ruby trunk Feature#2013][Rejected] [PATCH] a = *b calls b.*@
From:
mame@...
Date:
2017-10-22 00:29:19 UTC
List:
ruby-core #83482
Issue #2013 has been updated by mame (Yusuke Endoh).
Status changed from Assigned to Rejected
I'm closing this ticket since the discussion has been stalled completely.
I still think this is an interesting proposal. If you (or anyone else) are interested in this feature, please create a new ticket. It would be good to reimplement it for trunk, and to investigate its merit on real-world applications and the compatibility problem.
----------------------------------------
Feature #2013: [PATCH] a = *b calls b.*@
https://bugs.ruby-lang.org/issues/2013#change-67489
* Author: jeremye (Jeremy Evans)
* Status: Rejected
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: Next Major
----------------------------------------
=begin
This makes the * operator operate more similarly to the + and - operators. The binary versions of + and - call methods named + and -, while the unary versions call methods named +@ and -@. The binary * operator calls the method named *, but the unary * operator calls the method to_a currently, and used to call to_ary in 1.8.6 (and at some point may have called to_splat).
I think this makes for more consistent behavior, and hopefully it isn't just a foolish consistency. I brought up this idea as a question in Shugo Maeda's presentation at RubyKaigi 2009, and discussed it with Matz at Lone Star Ruby Conf 2009, and he thought the idea had merit.
Here's a basic example how this would look:
class MultiplePersonality
def *@
[self, [self, self]]
end
end
mp = MultiplePersonality.new
p1, mp2 = *mp
This comes with a patch that appears to work from my simple testing, but this is my first time working with the internal ruby code, so I apologize in advance if it doesn't do things correctly.
The patch modifies parse.y so the above is no longer a syntax error. It adds a USTAR token to the parser to represent that *@ token. It modifies the splatting to call *@ instead of to_a. Also, for backwards compatibility, it adds *@ to BasicObject, and has it call to_a if it responds to to_a. This allows code that defines to_a and expects that the unary * operator will call to_a to still work.
This patch is mostly for consistency, but it also allows the programmer to make to_a return one thing, and the unary * operator return something else. I can think of the following use case:
# Represents an abstract set of rows in the database
class Dataset
def to_a
retrieve_database_rows
end
def *@
[self]
end
end
dataset = Dataset.new
# Explicitly asking for an array means I want
# an array of database rows represented by the
# dataset.
rows = dataset.to_a
# If the dataset had any rows, I want to debug print
# each row separately. However, if it did not have
# any rows, I want to debug print the dataset itself.
p(*(rows.empty? ? dataset : rows))
I'd like to thank Eleanor McHugh for helping me find the key part of ruby that needed to be modified to support this (in vm_insnhelper.c).
=end
---Files--------------------------------
unary_star_op_svn.diff (3.99 KB)
--
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>