[#55222] [ruby-trunk - Feature #8468][Feedback] Remove $SAFE — "shugo (Shugo Maeda)" <redmine@...>
20 messages
2013/06/01
[#55230] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55252] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55276] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation — Tanaka Akira <akr@...>
2013/5/31 zzak <ko1@atdot.net>:
9 messages
2013/06/03
[#55278] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/03
[#55285] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
The original wording was:
[#55288] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55289] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
I fail to see the difference, please provide a patch to make it more clear.
[#55290] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55291] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Tanaka Akira <akr@...>
2013/06/04
2013/6/4 David MacMahon <davidm@astro.berkeley.edu>:
[#55297] [ruby-trunk - Bug #8486][Open] Random segmentation fault — "manudwarf (Emmanuel Bourgerie)" <manu.dwarf@...>
4 messages
2013/06/04
[#55305] [ruby-trunk - Bug #8489][Open] Tracepoint API: B_RETURN_EVENT not triggered when "next" used — deivid (David Rodríguez) <deivid.rodriguez@...>
7 messages
2013/06/04
[#55312] [ruby-trunk - Bug #8495][Open] include/ruby/win32.h assumes that __STRICT_ANSI__ isn’t set — "now (Nikolai Weibull)" <now@...>
4 messages
2013/06/05
[#55330] [ruby-trunk - Feature #8499][Assigned] Importing Hash#slice, Hash#slice!, Hash#except, and Hash#except! from ActiveSupport — "mrkn (Kenta Murata)" <muraken@...>
30 messages
2013/06/06
[#55416] CI failures: Test IO and cleanup failures — Luis Lavena <luislavena@...>
Hello,
3 messages
2013/06/10
[#55528] [ruby-trunk - Bug #8538][Open] c method not pushed into the callstack when called, but popped when returned — deivid (David Rodríguez) <deivid.rodriguez@...>
9 messages
2013/06/17
[#55530] [ruby-trunk - Feature #8539][Open] Unbundle ext/tk — "naruse (Yui NARUSE)" <naruse@...>
10 messages
2013/06/17
[#55557] [ruby-trunk - misc #8543][Open] rb_iseq_load — "alvoskov (Alexey Voskov)" <alvoskov@...>
47 messages
2013/06/19
[#65574] [ruby-trunk - Feature #8543] rb_iseq_load
— billk@...
2014/10/09
Issue #8543 has been updated by B Kelly.
[#55578] [ruby-trunk - Feature #8553][Open] Bignum#size (and Fixnum#size) — "akr (Akira Tanaka)" <akr@...>
6 messages
2013/06/21
[#55580] [CommonRuby - Feature #8556][Open] MutexedDelegator as a trivial way to make an object thread-safe — "headius (Charles Nutter)" <headius@...>
19 messages
2013/06/21
[#55590] [ruby-trunk - Bug #8560][Open] CSV, skip_lines option causes error when passing a string — "kstevens715 (Kyle Stevens)" <kstevens715@...>
5 messages
2013/06/22
[#55638] [CommonRuby - Feature #8568][Open] Introduce RbConfig value for native word size, to avoid Fixnum#size use — "headius (Charles Nutter)" <headius@...>
18 messages
2013/06/24
[#55678] [ruby-trunk - Feature #8572][Open] Fiber should be a Enumerable — "mattn (Yasuhiro Matsumoto)" <mattn.jp@...>
13 messages
2013/06/28
[#55690] [ANN] Developer Meeting - 12-07-2013 at 23:00 UTC — Aaron Patterson <tenderlove@...>
Hi everyone!
7 messages
2013/06/28
[#55699] [ruby-trunk - Feature #8579][Open] Frozen string syntax — "charliesome (Charlie Somerville)" <charliesome@...>
20 messages
2013/06/29
[ruby-core:55612] [ruby-trunk - Feature #6373] public #self
From:
"headius (Charles Nutter)" <headius@...>
Date:
2013-06-23 18:51:28 UTC
List:
ruby-core #55612
Issue #6373 has been updated by headius (Charles Nutter).
phluid61 (Matthew Kerwin) wrote:
> laise (Alexey Chernenkov) wrote:
> > It is a VERY usefull feature! Can't understand why #tap still need to be used with block only.
>
> Because it's called "tap." Tap doesn't "return self", it taps into an execution flow, extracting an intermediate value for inspection without interrupting the original flow. The analogy is literally tapping a hole in a pipe, to extract liquid samples at various phases in a process. (Also think of tapping a phone line.) Changing its semantics to a straight-up "returns self" method would just make it idiosyncratic, instead of metaphoric.
I still like #tap.
1. It would only require removal of the block-yielding requirement.
2. It's functionally equivalent to tapping into execution flow but doing nothing, as in tap {}. I think the objection that it no longer means we're tapping execution flow is a bit pedantic; we *are* tapping execution flow, but the only operation we seek is the reference to the object.
My favorite remains #self, but I can appreciate objections, especially confusion over "self" and "obj.self" and especially "self.self" if #self can be overridden. It does have the advantage that there's probably fewer libraries that define their own "self" method than any other suggestion here.
Other systems I know would use #identity. It also maps to functional programming language for a function that just returns its sole argument (in this case, the 0th argument, the object itself). I would support #identity as well.
> Matz wrote:
> > The point is when we see the code like:
> >
> > [1,2,3,4,5,1,2,2,3].group_by(&:self)
> >
> > sometimes it would be less intuitive that self refers elements in the array, not self in the scope.
>
> I have trouble imagining such a scenario. I actually think the `some_array.group_by(&:self)` example is a strong plus for this feature.
>
> I'm also not entirely convinced it's really YAM, since 'self' is already a word in the language, all we're doing is pushing it from keyword to keyword+method, i.e. making it more easily accessible from outside the instance. Even more so since this use-case is really the only place it will ever show up; if there was another way to to_proc the 'self' keyword to make it easy to pass to a method like group_by I'd be for that as well/instead.
Another option based on matz's objection: #reference. We want a method that returns the reference to the object we're calling against. #reference seems logical.
[1,2,3,4,5,1,2,2,3].group_by(&:reference)
Variations on this might be #self_reference, #self_ref, #selfref. Also #self_object, #self_obj, #selfobj.
#self and #identity are probably the most likely to be guessed by a new user.
----------------------------------------
Feature #6373: public #self
https://bugs.ruby-lang.org/issues/6373#change-40101
Author: trans (SYSTEM ERROR)
Status: Feedback
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: next minor
=begin
This was recently suggested to me as an extension:
class Object
# An identity method that provides access to an object's 'self'.
#
# Example:
# [1,2,3,4,5,1,2,2,3].group_by(&:identity)
# #=> {1=>[1, 1], 2=>[2, 2, 2], 3=>[3, 3], 4=>[4], 5=>[5]}
#
def identity
self
end
end
First, is such a method commonly useful enough to warrant existence?
Second, it makes me wonder if #self should be a public method in general.
=end
--
http://bugs.ruby-lang.org/