Issue #8976 has been updated by headius (Charles Nutter).


brixen (Brian Shirai) wrote:
> For consistency sake, it should be noted that, in fact, this is exactly what the existing encoding pragma does, and it's also the express purpose of refinements.

The encoding directive changes the interpretation of the bytes within strings, but does not change their behavior. If m17n is working properly, you may never even see a difference in code, since even strings with different encodings can be negotiated into combining, matching regexp, and converting to other encodings.

Refinements change the meaning of code within a lexical scope...not within an entire file (unless it is the file's scope that is being refined). This is more analogous to instance_eval on a block, which changes what "self" methods are called against. You are correct that they do change the meaning of code within their scope, but whether that's a good feature or not is beyond the scope of this discussion. I do not particularly like refinements.

A frozen string directive would actually change the behavior of the strings in that file, making operations that worked before fail to work under the directive. Encoding does not make some methods on string start to raise errors, except where you may have differing encodings (which can happen without an encoding directive too).

> Hence, a more nuanced argument than this broad stroke of "very bad idea" may be needed.

I'm not sure this is the place to have a meta-argument about how to argue for or against this proposal. But since you suggest a more nuanced argument, I suggest you look at the original points in my comment that explain *why* it would be a bad idea.

Do you have any arguments to make for or against this proposal?
----------------------------------------
Feature #8976: file-scope freeze_string directive
https://bugs.ruby-lang.org/issues/8976#change-42223

Author: akr (Akira Tanaka)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: current: 2.1.0


Yesterday, we had a face-to-face developer meeting.
https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20131001Japan
Several committers attended.
matz didn't attended, though.  (This means this issue is not concluded.)

We believe we found a better way to freeze static string literals for
less GC pressure.
"static string literal" is a string literal without dynamic expression.

Currently, f-suffix, "..."f, is used to freeze a string literal to avoid
String object allocation.

There are several problems for f-suffix:

* The notation is ugly.
* Syntax error on Ruby 2.0.
  We cannot use the feature in version independent libraries.
  So, it is difficult to deploy.
* Need to modify for each string literal.
  This is cumbersome.

The new way we found is a file-scope directive as follows

  # freeze_string: true

The above comment at top of a file changes semantics of
static string literals in the file.
The static string literals will be frozen and always returns same object.
(The semantics of dynamic string literals is not changed.)

This way has following benefits:

* No ugly f-suffix.
* No syntax error on older Ruby.
* We need only a line for each file.

We can write version independent library using frozen static string literals as follows.

* Use the directive at top of the file: # freeze_string: true
  Older Ruby ignore this as a comment.
* Use "...".dup for strings to be modified.
  Older Ruby has small disadvantage: useless dup is called.

Note that the directive effects all static string literals regardless of
single quotes, double quotes, %q-string, %qq-string and here documents.
The reason that the directive is effective not only single quotes is
we want to use escape sequences such as \n in frozen string literals.

Also note that similar directive is already exist:

  % ruby -w -e '
  def m
    end
  '
  -e:3: warning: mismatched indentations at 'end' with 'def' at 2
  % ruby -w -e '# -*- warn_indent: false -*-
  def m
    end
  '

The directive, warn_indent: false, disables "mismatched indentations" warning.

nobu implemented this feature in the meeting.
Please attach the patch, nobu.



-- 
http://bugs.ruby-lang.org/