[#65451] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
9 messages
2014/10/07
[#65458] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/07
[email protected] wrote:
[#65502] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/08
Eric Wong <[email protected]> wrote:
[#65538] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/09
Eric Wong <[email protected]> wrote:
[#65549] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— SASADA Koichi <ko1@...>
2014/10/09
On 2014/10/09 11:04, Eric Wong wrote:
[#65551] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/09
SASADA Koichi <[email protected]> wrote:
[#65453] [ruby-trunk - Feature #10328] [PATCH] make OPT_SUPPORT_JOKE a proper VM option — ko1@...
Issue #10328 has been updated by Koichi Sasada.
3 messages
2014/10/07
[#65559] is there a name for this? — Xavier Noria <fxn@...>
When describing stuff about constants (working in their guide), you often
7 messages
2014/10/09
[#65560] Re: is there a name for this?
— Nobuyoshi Nakada <nobu@...>
2014/10/09
On 2014/10/09 20:41, Xavier Noria wrote:
[#65561] Re: is there a name for this?
— Xavier Noria <fxn@...>
2014/10/09
On Thu, Oct 9, 2014 at 1:59 PM, Nobuyoshi Nakada <[email protected]> wrote:
[#65566] [ruby-trunk - Feature #10351] [Open] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been reported by Shyouhei Urabe.
3 messages
2014/10/09
[#65741] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race — Nobuyoshi Nakada <nobu@...>
On 2014/10/16 10:10, [email protected] wrote:
5 messages
2014/10/16
[#65742] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race
— Eric Wong <normalperson@...>
2014/10/16
Nobuyoshi Nakada <[email protected]> wrote:
[#65750] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race
— Tanaka Akira <akr@...>
2014/10/16
2014-10-16 12:48 GMT+09:00 Eric Wong <[email protected]>:
[#65753] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
3 messages
2014/10/16
[#65818] [ruby-trunk - Feature #10351] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been updated by Shyouhei Urabe.
3 messages
2014/10/20
[ruby-core:65860] [ruby-trunk - Feature #10394] An instance method on Enumerator that evaluates the block under with self being the block variable.
From:
andrew@...
Date:
2014-10-23 00:24:36 UTC
List:
ruby-core #65860
Issue #10394 has been updated by Andrew Vit.
It might be confusing if such a thing only exists for Enumerator blocks and nothing else.
~~~ruby
["foo", "bar"].map.as_self { clear }
["foo", "bar"].tap.as_self { clear } # (not an Enumerator)
~~~
What would be the correct receiver in your proposal for the following example? What happens when the method is not defined in the block's "self" object?
~~~ruby
@members = ["foo", "bar"]
def transform_all
@members.each.as_self { transform }
end
def transform
raise "this one?"
end
~~~
A little bit related: #10095 (for the proposed syntax "as" vs. "as_self")
----------------------------------------
Feature #10394: An instance method on Enumerator that evaluates the block under with self being the block variable.
https://bugs.ruby-lang.org/issues/10394#change-49595
* Author: Tsuyoshi Sawada
* Status: Feedback
* Priority: Normal
* Assignee:
* Category:
* Target version:
----------------------------------------
**Background**
There has been desire to omit the `| |` and the explicit receiver in a block used with an enumerator or an enumerable. Currently, when the content of the block is a single method that takes no argument, symbol-to-proc is used with the `&` syntax so that:
~~~ruby
["foo", "bar"].map{|s| s.upcase}
~~~
can be written as:
~~~ruby
["foo", "bar"].map(&:upcase)
~~~
There has repeated been proposals (#8987, #9076, #10318) that express this desire to do this even when the block involves a method chain or a method with arguments like the following:
~~~ruby
["foo", "bar"].map{|s| s.concat("ber")}
[" foo ", "\tbar\n"].map{|s| s.strip.upcase}
~~~
Focus has been on modifying how a block is passed to the enumerable/enumerator, and there has not been consensus on how the syntax should be.
**Proposal**
Unlike the earlier proposals, I suggest that there should be an instance method on `Enumerator`, let's say `Enumerator#as_self`, that evaluates the block each time with `self` being the block variable that would be passed otherwise. With such method, the cases above would be written like this:
~~~ruby
["foo", "bar"].map.as_self{concat("ber")}
[" foo ", "\tbar\n"].map.as_self{strip.upcase}
~~~
This adds no modification to the syntax, it just requires a new method `Enumerator#as_self` to be implemented. I consider this method being along the lines of `Enumerator#with_index`, `Enumerator#with_object`; it intervenes between an enumerator (related to a block-taking method) and a block, and let the block-taking method work in a modified way.
It resembles `instance_eval`, but is different in that it assigns to `self` what would be a block variable (which changes for each iteration), instead of assigning the receiver.
--
https://bugs.ruby-lang.org/
