Can someone explain the "write barrier" stuff? It's hard to glean what the problem is that they're solving here... And what they're saying about Arrays, Strings, Hash, etc, in relation to WB protected vs. WB unprotected.
What's New in Ruby 2.1 [pdf]
11–20 of 36 posts
Re: What's New in Ruby 2.1 [pdf]
#12I really like the ObjectSpace.trace_object_allocations addition. I had a quick look at the 2.1 docs for ObjectSpace and there seem to be all sorts of interesting methods in there reachable_objects_from(obj) and memsize_of(obj) for example. It looks like understanding memory usage and tracking down memory leaks will get a lot easier with 2.1. http://ruby-doc.org/stdlib-2.1.0/libdoc/objspace/rdoc/Object...
#reachable_objects_from was added in 2.0, and I think #memsize_of was introduced in one of the 1.9 releases. The documentation is new though. I wrote a little about them here: http://globaldev.co.uk/2013/03/ruby-2-0-0-in-detail/#id6
Ah nice, thanks, missed the part about requiring "objspace" to mix them in and assumed they would be on the already existing ObjectSpace module.
Re: What's New in Ruby 2.1 [pdf]
#13I'm looking forward to `def` returning a symbol (page 11). private static void def main(args) ...; end
That slide was a bit confusing for my underslept mind. Is that meant as an example of calling methods which work over the result of defining main (in this case static and void)?
If you say "private def methodname(args); end",
the "private" keyword already takes a symbol for a method name to privatize, so in this case the return of "def methodname(args); end" is ":methodname" which then gets passed to "private" and everything magically works.
Re: What's New in Ruby 2.1 [pdf]
#14I'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.
Re: What's New in Ruby 2.1 [pdf]
#15I'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 ta…
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
.
Re: What's New in Ruby 2.1 [pdf]
#16I'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 ta…
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 . Is "foo"f _not_ sending a message? If so, then what is it doing? If yes, then why new syntax?
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
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 for more discussion.
Re: What's New in Ruby 2.1 [pdf]
#17I'm looking forward to `def` returning a symbol (page 11). private static void def main(args) ...; end
That slide was a bit confusing for my underslept mind. Is that meant as an example of calling methods which work over the result of defining main (in this case static and void)?
yeah it's an example of how you could implement higher-level language features much easier if def returns a symbol rather than nil
Re: What's New in Ruby 2.1 [pdf]
#18I'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 ta…
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 . Is "foo"f _not_ sending a message? If so, then what is it doing? If yes, then why new syntax?
it is not sending a message any more than 0b100 is sending a message. this is syntax for a type.
Re: What's New in Ruby 2.1 [pdf]
#19I'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 ta…
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-prev...
Re: What's New in Ruby 2.1 [pdf]
#20I'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 ta…
[deleted]