[#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
ko1@atdot.net wrote:
[#65502] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/08
Eric Wong <normalperson@yhbt.net> wrote:
[#65538] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/09
Eric Wong <normalperson@yhbt.net> 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 <ko1@atdot.net> 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 <nobu@ruby-lang.org> 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, normal@ruby-lang.org 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 <nobu@ruby-lang.org> 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 <normalperson@yhbt.net>:
[#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:65761] Re: [ruby-trunk - Feature #8976] file-scope freeze_string directive
From:
Eric Wong <normalperson@...>
Date:
2014-10-16 07:53:46 UTC
List:
ruby-core #65761
akr@fsij.org wrote:
> Recent Eric Wong's effort reminds me this issue.
>
> I still think this issue is worth to consider.
>
> Ruby 2.1 changed the semantics of "...".freeze to avoid string allocation.
> It is not used extensively, I feel.
Right, "...".freeze is too ugly IMHO. Ruby should stay beautiful :)
> File scope directive provides a way to use frozen string literals with
> much fewer modification to programs.
>
> Also, I think frozen string literals is a better programming style.
> It needs dup call ("...".dup) for string literals to be modified.
I also think needing to call "...".dup is ugly and will break much
existing code[1].
> It makes us to prevent unintentional modification and
> we can distinguish string literals to be modified or not, more easily.
My concern is optimizing Ruby for the typical script language users[2],
not the (few) Rubyists who understand VM internals.
I prefer we continue to improve Ruby, transparently:
* 2.1 (past) - { "str" => ... }, "str".freeze
* 2.2 (done) - h["str"] (= ...)
* 2.2 (planned) - .{gsub/sub/tr/tr_s}(["str"]|/../, "str"), ==, %,
many more core (cfunc) methods
All of the above are transparent to existing code.
> I would like that future Ruby (Ruby 3.0?) will interpret string
> literals as frozen by default.
> This issue can be considered as a migration path.
> We can introduce file-scope directive now and change the default at
> future when most programs uses frozen string literals.
I am against this; especially as a default for 3.0[1]. File scope
directives makes refactoring and reorganization of code more difficult:
move a method to a new file and behavior changes.
I hope we can implement more optimization transparently in the compiler.
For example; we should be able to optimize more cases:
def foo(a, b)
a.gsub(/baz/, b)
end
foo(a, "lit") # no dup if `a' is a string
I think we can also use use (internal) C-API changes to mark cfuncs as
taking const args. It would be useful for things like Hash#merge!, too;
not just string literals.
[1] - Even for Ruby 3.0; I strongly favor maintaining backwards
compatibility as much as possible in Ruby-land.
1.8 -> 1.9 was very painful for some users (including myself)