https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112013-02-07T22:13:40ZRuby Issue Tracking SystemRuby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=359812013-02-07T22:13:40Ztrans (Thomas Sawyer)
<ul></ul><p>I offer a slight modification that would ease the transition somewhat. Instead of renaming Hash, just add a new code class, e.g. Map or Index, that does as you suggest. Then at some major version change (3.0?) use {} -> Map, instead of {} -> Hash. This would give developers plenty of time to switch from {} to Hash.new where it would be necessary to do so.</p>
<p>Of course, the odds of this happening, despite the fact that it would improve the language by making it more intuitive in precisely the manner you describe, is asymptote to zilch.</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=359922013-02-07T23:39:34Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul></ul><p>Thomas, the reason I didn't suggest your approach is because it wouldn't really fix several use cases, such as the example pointed out in the description using the json gem. It will use rb_hash_new for instance:</p>
<p><a href="https://github.com/flori/json/blob/master/ext/json/ext/parser/parser.c#L112" class="external">https://github.com/flori/json/blob/master/ext/json/ext/parser/parser.c#L112</a></p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=359932013-02-07T23:40:52Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><blockquote>
<p>Since <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Make symbols and strings the same thing (Rejected)" href="https://redmine.ruby-lang.org/issues/7792">#7792</a> has been rejected (although I don't really understand the<br>
reason except people being afraid of changing I guess)</p>
</blockquote>
<p>Several reasons were given to you. I do not understand why you try to<br>
"summarize" them all by stating that "people are afraid of change".</p>
<p>Symbols and Strings are not the same internally.</p>
<p>If ruby would get rid of symbols, the language would be simnpler for<br>
newcomers. But why have symbols been exposed at the ruby-language<br>
level at all? That's right, because they are simply more efficient<br>
than Strings. And that has nothing to do with anyone being afraid<br>
of change.</p>
<p>What you basically tried in your earlier proposal was to change<br>
ruby to a completely different language, where Symbols would be<br>
gone. This is a huge conceptual change, an undertaking that would<br>
even interfere with major release versions. It would break old<br>
ruby code for only marginal gains. How could you state that<br>
people are "afraid of change" and this is the sole reason for<br>
the rejection of your proposal?</p>
<blockquote>
<p>h = {a: 1, 'a' => 2} This would only confuse people.</p>
</blockquote>
<p>Yes, this crap would confuse people.</p>
<p>I myself use the old syntax, and it is also the one<br>
ruby uses internally. You can see this by pasting<br>
the hash there into IRB - you will see that a: 1<br>
will become :a => 1.</p>
<p>I myself would rather like if this new syntax would<br>
not have been added at all. I dont like it, and even<br>
though you save a few keys, I think it adds more to<br>
confusion rather than make things really better.</p>
<p>I do agree with you that it is annoying that symbols<br>
and strings can be used for hash keys. When I write<br>
ruby code, I always have to ask myself whether I<br>
want to use a symbol or a string as key.</p>
<p>I do not however see how your proposal makes THIS<br>
very decision any simpler.</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=359962013-02-08T00:03:05Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul></ul><p>shevegen (markus heiler) wrote:</p>
<blockquote>
<blockquote>
<p>Since <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Make symbols and strings the same thing (Rejected)" href="https://redmine.ruby-lang.org/issues/7792">#7792</a> has been rejected (although I don't really understand the<br>
reason except people being afraid of changing I guess)</p>
</blockquote>
<p>Several reasons were given to you. I do not understand why you try to<br>
"summarize" them all by stating that "people are afraid of change".</p>
</blockquote>
<p>The only real reason I remember people mentioning is the performance thing and how they are different internally. It shouldn't really matter to the language design its implementation details (if they are different internally or not, for instance). And for the performance argument I really believe symbols cause more harm than good to the overall performance given all conversions that it will require in most code bases (even if you don't do that directly it is likely that you rely on some gem that will do that).</p>
<blockquote>
<p>If ruby would get rid of symbols, the language would be simnpler for<br>
newcomers. But why have symbols been exposed at the ruby-language<br>
level at all?</p>
</blockquote>
<p>Have no idea! My suspect is that someone thought: "hey maybe it would be a great idea if we could optimize some constant strings - we could create a symbol for that - hey, look at my micro-benchmarks, it really is a great idea!".</p>
<blockquote>
<p>That's right, because they are simply more efficient than Strings.</p>
</blockquote>
<p>On micro-benchmarks I agree they may do some small difference. On real world-case apps though I'd suspect its presence is actually causing code to perform worse.</p>
<blockquote>
<p>What you basically tried in your earlier proposal was to change<br>
ruby to a completely different language...</p>
</blockquote>
<p>Why do you think that removing symbols would change Ruby in a fundamental way? I believe 99.9% of all Ruby code would still work without any changes if :symbol was the same as 'symbol'.freeze.</p>
<blockquote>
<p>This is a huge conceptual change</p>
</blockquote>
<p>This is your opinion. I don't agree.</p>
<blockquote>
<p>..I myself would rather like if this new syntax would<br>
not have been added at all. I dont like it, and even<br>
though you save a few keys</p>
</blockquote>
<p>The problem is not saving keys for my particular case. It is pretty natural to me when I'm typing to find the comma (:). Greater than signals (>) and, specially the equals (=) symbol require much more effort, which makes a big difference when you're creating a hash with many keys. Those two symbols are also very far from each other.</p>
<blockquote>
<p>I do agree with you that it is annoying that symbols<br>
and strings can be used for hash keys. When I write<br>
ruby code, I always have to ask myself whether I<br>
want to use a symbol or a string as key.</p>
</blockquote>
<p>That is exactly the reason why I created this ticket.</p>
<blockquote>
<p>I do not however see how your proposal makes THIS<br>
very decision any simpler.</p>
</blockquote>
<p>Simple, you don't have to worry about it anymore. Just don't think. If you've typed a symbol, that's fine. A string instead? No problem. Both should work interchangeable:</p>
<p>h = {a: 1, 'b' => 1}<br>
h['a'] == h[:b] # == 1</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=359982013-02-08T00:53:17Zyorickpeterse (Yorick Peterse)yorickpeterse@gmail.com
<ul></ul><blockquote>
<p>The only real reason I remember people mentioning is the performance<br>
thing and how they are different internally. It shouldn't really<br>
matter to the language design its implementation details (if they are<br>
different internally or not, for instance).</p>
</blockquote>
<p>There are so many cases where the implementation of X does affect its<br>
presentation. The way your database tables are layed out will ultimately<br>
affect your views. Is this bad too? No, it's a fundamental part of how<br>
things work.</p>
<p>While in many cases you can work around that and come up with a language<br>
design that isn't too heavily influenced by its implementation it would<br>
in this case fundamentally change the way MRI works. On top of that it<br>
would mean that all the other Ruby implementations such as JRuby and<br>
Rubinius had to be modified as well to be compatible with the Ruby<br>
specification.</p>
<p>I think the latter is something a lot of people don't think about. A<br>
change this big doesn't just affect the people using MRI, it affects<br>
every developer and every implementation out there. It will also affect<br>
existing resources such as books and tutorials as basically everything<br>
has to be re-written from scratch. The amount of effort required for<br>
this is way too much for it to make a change that can be solved in many<br>
different (and much easier) ways.</p>
<blockquote>
<p>And for the performance argument I really believe symbols cause more<br>
harm than good to the overall performance given all conversions that<br>
it will require in most code bases (even if you don't do that directly<br>
it is likely that you rely on some gem that will do that).</p>
</blockquote>
<p>I'd be interested in seeing the actual numbers for this. I also find it<br>
interesting to see that your general opinion seems to be "the<br>
performance overhead of this change is not important" yet you do seem to<br>
care about the overhead of converting Symbols to Strings. I find this a<br>
rather contradicting opinion but maybe I'm misunderstanding things.</p>
<blockquote>
<p>Have no idea! My suspect is that someone thought: "hey maybe it would<br>
be a great idea if we could optimize some constant strings - we could<br>
create a symbol for that - hey, look at my micro-benchmarks, it really<br>
is a great idea!".</p>
</blockquote>
<p>Yes, Matz took some crystal meth one evening and decided to introduce<br>
Symbols because he thought it was a fun idea to (apparently) piss people<br>
off with it.</p>
<p>If you honestly believe choices like these were made randomly or because<br>
of some hypothetical micro benchmark I suggest you actually spend some<br>
time getting to know the MRI code base. As with many things getting to<br>
know the inner workings of something will help you understand why<br>
choices were made, in this case I think it can greatly help you clear up<br>
your mind about making such a big change as well as understanding as to<br>
why it's not going to happen any time soon.</p>
<blockquote>
<p>On micro-benchmarks I agree they may do some small difference. On real<br>
world-case apps though I'd suspect its presence is actually causing<br>
code to perform worse.</p>
</blockquote>
<p>Based on what? The conversion of a Symbol to a String is no more<br>
in-efficient than creating a String yourself. Again show a benchmark if<br>
you're so convinced this is not the case.</p>
<blockquote>
<p>Why do you think that removing symbols would change Ruby in a<br>
fundamental way? I believe 99.9% of all Ruby code would still work<br>
without any changes if :symbol was the same as 'symbol'.freeze.</p>
</blockquote>
<p>See my comment above about all the implementations and resources having<br>
to be changed. It would also require substantial changes of the MRI<br>
source code. This would be a non trivial change.</p>
<blockquote>
<p>This is your opinion. I don't agree.</p>
</blockquote>
<p>Again take a look at the MRI code base before you disagree on this<br>
matter.</p>
<p>On another note, you also seem to be unaware that it's not trivial to<br>
suddenly replace the usage of Hash with LazyDeveloperHash. Yes, in the<br>
Ruby source code it might be easier but at least in the C code it's<br>
going to take time and effort for something that has little value.</p>
<p>In your other threads I gave you various examples on how you can work<br>
around your issue and even do so in such a way that will save you a lot<br>
of future work. However, it seems you're hell bent on ignoring that and<br>
continue to argue about why you disagree with something you (at least<br>
from my point of view) don't have a good understanding of.</p>
<p>This is also going to be my last Email for these 3 (or 4 now?)<br>
discussions. I've given plenty of examples and explanations (and so have<br>
others) and I have no interest anymore in trying to explain it.</p>
<p>Yorick</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=360032013-02-08T03:23:43Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul></ul><p>Em 07-02-2013 13:51, Yorick Peterse escreveu:</p>
<blockquote>
<p>...</p>
<blockquote>
<p>And for the performance argument I really believe symbols cause more<br>
harm than good to the overall performance given all conversions that<br>
it will require in most code bases (even if you don't do that directly<br>
it is likely that you rely on some gem that will do that).</p>
</blockquote>
<p>I'd be interested in seeing the actual numbers for this. I also find it<br>
interesting to see that your general opinion seems to be "the<br>
performance overhead of this change is not important" yet you do seem to<br>
care about the overhead of converting Symbols to Strings. I find this a<br>
rather contradicting opinion but maybe I'm misunderstanding things.</p>
</blockquote>
<p><a href="https://gist.github.com/rosenfeld/4732737" class="external">https://gist.github.com/rosenfeld/4732737</a></p>
<p>So, if your program relies on HWIA behavior and is converting regular<br>
hashes into HWIA, it would perform much worse then if the hash syntax<br>
already created HWIA. Also libraries like Sequel will call to_sym on<br>
string values returned from the database as column names. Then the<br>
overall performance would be slower due to unnecessary conversions<br>
between symbols and strings that wouldn't be required if regular hashes<br>
behaved like HWIA.</p>
<p>And this is just a simplistic case. What if I had to scan an entire<br>
random object resulted from a call to JSON.parse and find all hashes to<br>
manually replace them by a HWIA version?</p>
<p>This is way more common than you might expect in lots of gems and code<br>
out there. That is why I believe that the overall performance of most<br>
Ruby code in the real-world industry have their performance degraded by<br>
the existence of symbols and by them returning false when compared to<br>
equivalent strings.</p>
<blockquote>
<p>...<br>
On another note, you also seem to be unaware that it's not trivial to<br>
suddenly replace the usage of Hash with LazyDeveloperHash. Yes, in the<br>
Ruby source code it might be easier but at least in the C code it's<br>
going to take time and effort for something that has little value.</p>
</blockquote>
<p>You're saying that it has little value. What if someone decides that he<br>
would like to spend his (not yours) time making the required changes in<br>
the C code? Would this problem be gone?</p>
<blockquote>
<p>In your other threads I gave you various examples on how you can work<br>
around your issue</p>
</blockquote>
<p>You didn't understand the issue. I showed you a real example where you<br>
could show me how to optimize it but you haven't done so:</p>
<p><a href="https://bugs.ruby-lang.org/issues/7792#note-23" class="external">https://bugs.ruby-lang.org/issues/7792#note-23</a></p>
<p>You just assumed that Sequel took the wrong decision while deciding for<br>
using symbols as keys instead of strings. Jeremy Evans (Sequel's<br>
maintainer) doesn't seem to support your opinion on that and explains<br>
why he thinks Sequel should keep using symbols as keys.</p>
<p>But this is a real gem used in a real-world application published in the<br>
web. And this application would not only be easier to write and maintain<br>
if hash syntax created HWIA but this app would also perform better.</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=360232013-02-08T08:23:09Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>rosenfeld (Rodrigo Rosenfeld Rosas) wrote:</p>
<blockquote>
<p>Have no idea! My suspect is that someone thought: "hey maybe it would<br>
be a great idea if we could optimize some constant strings - we could<br>
create a symbol for that - hey, look at my micro-benchmarks, it really<br>
is a great idea!".</p>
</blockquote>
<p>Ruby's symbols hail directly from Smalltalk (early 1970's) and are analogous<br>
to Lisp atoms (early 1960's.)</p>
<p>I think the challenge in Ruby is there are multiple competing reasons symbols<br>
are used, from a developer perspective:</p>
<ul>
<li>
<p>performance (A symbol exists once in memory and can be compared quickly)</p>
</li>
<li>
<p>immutability (Symbols implicitly behave as though 'frozen')</p>
</li>
<li>
<p>appealing syntax (If symbols were uglier to create than strings, instead<br>
of being totally sexy, we likely wouldn't be having this<br>
discussion.)</p>
</li>
</ul>
<p>Presumably many Rubyists gravitate toward the appealing syntax, without<br>
being aware of Symbol's other properties -- and, well, the accompanying half-<br>
century of computing history?</p>
<p>Personally I'd love for symbols to be able to be garbage collected, though I<br>
understand the technical challenges. I'd be happy if a symbol-string<br>
"indifferent" Hash alternative were available in core (is there a better name<br>
than the Rails thing?) If we were starting over at Ruby 1.0, I probably would<br>
be fine with the :symbol syntax just being an alternative way to create<br>
regular strings. Today, though, symbols are part of the language, and they're<br>
distinct from strings. I'm OK with that.</p>
<p>Regards,</p>
<p>Bill</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=419302013-09-23T19:27:05ZSing9898 (Sing Lou)3b06e8d4@opayq.com
<ul></ul><p>I am so glad this ticket wasn't rejected because it is a constructive solution to one of the biggest Ruby frustrations. (Even if you understand the difference between strings and symbol it still causes many hidden bugs).</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=419312013-09-23T19:35:19ZSing9898 (Sing Lou)3b06e8d4@opayq.com
<ul></ul><p>the confusing became probably more immediate after the introduction of the new {a:"b"} syntax.<br>
because for novices it might not be clear whether {a:"b"} means {"a"=>"b"} or {:a =>"b"}</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=419332013-09-23T19:43:04ZHanmac (Hans Mackowiak)hanmac@gmx.de
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/7459">@Sing9898 (Sing Lou)</a> no you cant do that because it could break existing ruby code</p>
<p>{a:"b"} is the short form for {:a => "b"}, you can not easily change it to {"a"=>"b"} without breaking multiple ruby programs</p>
<p>i think you still does not understand that Symbols are sometimes better than Strings</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=473852014-06-26T12:02:48Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul><li><strong>File</strong> <i>feature-7797.pdf</i> added</li></ul><p>Attached an slide for this proposal</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=474612014-06-30T04:42:06Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>received, thanks!</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=474792014-06-30T14:25:09Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul></ul><p>Hi Rodrigo,</p>
<p>Cur redmine couldn't handle your file named feature-7797.pdf.<br>
Please remove & upload it again.</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=474832014-06-30T17:05:49Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul><li><strong>File</strong> <i>feature-7797.pdf</i> added</li><li><strong>File</strong> <a href="/attachments/4514">redmine-bug.jpg</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4514/redmine-bug.jpg">redmine-bug.jpg</a> added</li></ul><p>I don't think I have permissions to remove it. I'm reattaching it.</p>
<p>But indeed Redmine is buggy here on Chrome when I try to attach a PDF. See attached screenshot (It attached the PDF twice and I removed the duplicate)</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=474842014-06-30T17:11:21Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul></ul><p>Chrome reported this in the console: "Uncaught RangeError: Maximum call stack size exceeded."</p>
<p>The stack goes something like this:</p>
<pre><code>v.extend.clone jquery-1.8.3-ui-1.9.2-ujs-2.0.3.js?1402908441:2
(anonymous function) jquery-1.8.3-ui-1.9.2-ujs-2.0.3.js?1402908441:2
(anonymous function) jquery-1.8.3-ui-1.9.2-ujs-2.0.3.js?1402908441:2
v.extend.map jquery-1.8.3-ui-1.9.2-ujs-2.0.3.js?1402908441:2
v.fn.v.map jquery-1.8.3-ui-1.9.2-ujs-2.0.3.js?1402908441:2
v.fn.extend.clone jquery-1.8.3-ui-1.9.2-ujs-2.0.3.js?1402908441:2
addInputFiles attachments.js?1402908441:118
onchange 7797:1
v.extend.clone jquery-1.8.3-ui-1.9.2-ujs-2.0.3.js?1402908441:2
...
</code></pre> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=474852014-06-30T17:14:21Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/4517">feature-7797.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4517/feature-7797.pdf">feature-7797.pdf</a> added</li></ul><p>Trying again, using Firefox now.</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=480352014-07-26T04:47:26Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>File</strong> deleted (<del><i>feature-7797.pdf</i></del>)</li></ul> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=480362014-07-26T04:47:38Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>File</strong> deleted (<del><i>feature-7797.pdf</i></del>)</li></ul> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=480372014-07-26T04:51:23Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>Hi,</p>
<p>I have to reject this issue, since this will introduce a huge incompatibility. Even I don't have right to break thousands of programs that use both symbols and strings in keys.</p>
<p>Another idea is introducing mode to make a hash indifferent, but introducing mode is kinda against recent trend of immutability.</p>
<p>Matz.</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=480402014-07-26T05:10:31Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Note that we alrady have Hash#compare_by_identity.</p>
<p>Matz.</p> Ruby master - Feature #7797: Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccesshttps://redmine.ruby-lang.org/issues/7797?journal_id=481102014-07-28T13:15:26Zrosenfeld (Rodrigo Rosenfeld Rosas)rr.rosas@gmail.com
<ul></ul><p>What do you mean by introducing a mode to make a hash indifferent? You mean another method changing how the Hash works, just like compare_by_identity? Or do you mean some Ruby command-line flag option? I wouldn't like the latter but maybe the former could work fine.</p>
<p>If you were talking about the former would you mind expanding on why such change would be relevant to the immutability thing? I don't really think worrying about immutability makes much sense in Ruby. Languages that want to get the performance benefits from immutable constructs usually do that from the very beginning since it's very hard to try to introduce this concept later in a general purpose OO language...</p>
<p>Immutability is not free and giving up of some features because of immutability specially when the lack of the features won't give you any immediate advantages on performance doesn't make much sense to me.</p>
<p>I don't see immutability as the single path to meet performance or parallelism. C++, Java and other languages can perform pretty well with mutable structs. I do think MRI should be more concerned about removing the lock and allow multiple threads to run Ruby code at the same time like other Ruby VMs do. This makes more sense to me than trying to move Ruby to a direction where immutability would be the main goal and then prevent some useful features from being implemented instead.</p>