From: Eric Wong Date: 2013-10-14T08:25:06+00:00 Subject: [ruby-core:57845] Re: [ruby-trunk - Feature #8992] Use String#freeze and compiler tricks to replace "str"f suffix Nobuyoshi Nakada wrote: > (13/10/14 8:40), sam.saffron (Sam Saffron) wrote: > > Issue #8992 has been updated by sam.saffron (Sam Saffron). > > Thank you for summarizing. > > > There are 3 things being discussed here, I think it is fairly important we split them out. > > > > 1. Parser optimisation for "string".freeze > > > 1) is completely doable with little side-effects. My caveat is that if #1 is the only thing done, the semantics for #freeze depend on the invocation. That said, this is minor. I totally accept that and prefer "string".freeze to "string"f. > > It's a part of byte-code optimization, not parser. Since we have done > it already for several methods, no problem there. So can we move this optimization to the parser instead? I think Sam means: # optimized literal by parser. This may use pooled string since # the string never existed in ObjectSpace before this line of code: "string".freeze However, if .freeze operates on a variable (and not literal): # leave this optimized by parser to avoid incompatibility a = "string" a.freeze => preserve existing behavior > > 2. Unconditionally have #freeze return a pooled string > > 3. Change the semantics of #freeze so it amends the current object and operates like .NET / Java intern does. > > > 2) without 3) really scares me. > > > > Imagine the odd semantics: > > > > a = "hello" > > a.freeze # freezes one RVALUE in memory and returns a different RVALUE Yes, this scares me if a.freeze made a different RVALUE > > > > As to 3) I don't think it can be implemented in MRI. If an RVALUE is moved in memory, MRI is going to have to crawl the heap and rewrite all the RVALUE that hold a ref to it, it does not keep track of this internally. > > Totally agree. > > 2+3 is wrong idea, I think. Agreed.