5 ms·

I'm uncertain why they've added an `f` suffix for frozen string literals/instantiation. I can understand needing to freeze an existing String, but you can do t

I'm uncertain why they've added an `f` suffix for frozen string literals/instantiation. I can understand needing to freeze an existing String, but you can do that with Object#freeze, but a literal syntax seems to overlap with the usage of Symbols. The only benefit I can think of is not needing to use Symbol#to_s when working alongside strings. I'm not saying frozen strings are not useful, because they can be after taking in some input/params to work with/store, but a literal syntax seems extremely edge-case-y. Now instead of "foo".freeze it's "foo"f, but how frequently will that save you time/trouble? The bigger implication is that slides 23/24 shows that immutable strings and symbols will share their heap locations, if I'm reading the diagrams correctly, but have different object_ids. This seems a bit bewildering and focused on micro-optimization, which is not the mental model I have in mind when I'm coding in a very high level language. It's also blurring the semantic difference between Symbols and Strings.

jamesbritt 13y ago
Now instead of "foo".freeze it's "foo"f, but how frequently will that save you time/trouble? Worse, it seems to break the model of "interact with objects by sending messages", where you send a message using <object>.<message> Is "foo"f _not_ sending a message? If so, then what is it doing? If yes, then why new syntax?
- bct 13y ago
  It's not sending a message - that would defeat the purpose. It's constructing a frozen string, reusing an existing one when possible. Prior to 2.1: def foo "bar".freeze end does these things every time `foo` is called: 1. copies the characters 'b', 'a', and 'r' into a mutable string 2. sends the message `freeze` to the new string, which... 3. marks the string as frozen. In 2.1 `"bar".freeze` is equivalent to `"bar"f`, which will not make a copy every time `foo` is called. See https://bugs.ruby-lang.org/issues/8579 https://bugs.ruby-lang.org/issues/8579 for more discussion.
  - jamesbritt 13y ago
    I see. Thank you.
- aaronblohowiak 13y ago
  it is not sending a message any more than 0b100 is sending a message. this is syntax for a type.
jhawthorn 13y ago
The f suffix has been removed in favour of the existing "foo".freeze (which is now recognized and optimized in the parser) https://www.ruby-lang.org/en/news/2013/11/22/ruby-2-1-0-preview2-is-released/ https://www.ruby-lang.org/en/news/2013/11/22/ruby-2-1-0-prev... https://bugs.ruby-lang.org/issues/9042 https://bugs.ruby-lang.org/issues/9042
- Slackwise 13y ago
  That clears up the semantic similarity issue for me nicely. Having them as a literal was too awkward, and honestly, pretty ugly. Thanks for the heads-up!
deleted 13y ago
[deleted]
bct 13y ago
My understanding is that frozen strings (unlike Symbols) are garbage collected. This is useful because symbol construction can be used to DOS an application. (I agree that it's a weird, low level detail to have to think about.)
- derefr 13y ago
  Wait, so Ruby has the same problem with symbols that Erlang does with atoms? Why don't I constantly see warnings against using String#intern the way I do about list_to_atom/1?
  - brandonbloom 13y ago
    > Wait, so Ruby has the same problem with symbols that Erlang does with atoms? Yes. > Why don't I constantly see warnings against using String#intern the way I do about list_to_atom/1? Because leaking memory over time is pretty much the natural state of being for Ruby apps. Periodic process restarts are culturally A-OK. Leaking symbols are likely to be the least of your perf problems. But even in Erlang, the issue is only calling an interning operation on untrusted user data. In most real word use cases, you'll leak until a constant limit, which is probably no big deal. However, I've seen many Rails vulnerable to trivial DOS attacks by sending 1MB of random nonsense in a field known to be .to_sym-ed
deleted 13y ago
[deleted]

jamesbritt 13y ago

Now instead of "foo".freeze it's "foo"f, but how frequently will that save you time/trouble? Worse, it seems to break the model of "interact with objects by sending messages", where you send a message using <object>.<message> Is "foo"f _not_ sending a message? If so, then what is it doing? If yes, then why new syntax?

bct 13y ago
It's not sending a message - that would defeat the purpose. It's constructing a frozen string, reusing an existing one when possible. Prior to 2.1: def foo "bar".freeze end does these things every time `foo` is called: 1. copies the characters 'b', 'a', and 'r' into a mutable string 2. sends the message `freeze` to the new string, which... 3. marks the string as frozen. In 2.1 `"bar".freeze` is equivalent to `"bar"f`, which will not make a copy every time `foo` is called. See https://bugs.ruby-lang.org/issues/8579 https://bugs.ruby-lang.org/issues/8579 for more discussion.
- jamesbritt 13y ago
  I see. Thank you.
aaronblohowiak 13y ago
it is not sending a message any more than 0b100 is sending a message. this is syntax for a type.

jhawthorn 13y ago

The f suffix has been removed in favour of the existing "foo".freeze (which is now recognized and optimized in the parser) https://www.ruby-lang.org/en/news/2013/11/22/ruby-2-1-0-preview2-is-released/ https://www.ruby-lang.org/en/news/2013/11/22/ruby-2-1-0-prev... https://bugs.ruby-lang.org/issues/9042 https://bugs.ruby-lang.org/issues/9042

Slackwise 13y ago
That clears up the semantic similarity issue for me nicely. Having them as a literal was too awkward, and honestly, pretty ugly. Thanks for the heads-up!

deleted 13y ago

[deleted]

bct 13y ago

My understanding is that frozen strings (unlike Symbols) are garbage collected. This is useful because symbol construction can be used to DOS an application. (I agree that it's a weird, low level detail to have to think about.)

derefr 13y ago
Wait, so Ruby has the same problem with symbols that Erlang does with atoms? Why don't I constantly see warnings against using String#intern the way I do about list_to_atom/1?
- brandonbloom 13y ago
  > Wait, so Ruby has the same problem with symbols that Erlang does with atoms? Yes. > Why don't I constantly see warnings against using String#intern the way I do about list_to_atom/1? Because leaking memory over time is pretty much the natural state of being for Ruby apps. Periodic process restarts are culturally A-OK. Leaking symbols are likely to be the least of your perf problems. But even in Erlang, the issue is only calling an interning operation on untrusted user data. In most real word use cases, you'll leak until a constant limit, which is probably no big deal. However, I've seen many Rails vulnerable to trivial DOS attacks by sending 1MB of random nonsense in a field known to be .to_sym-ed

deleted 13y ago

[deleted]