< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事(スレッド移動)
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事(前)
<:同じ返事先を持つ記事(後)
---:分割してスレッド表示、再表示
| :分割して(縦)スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
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)