https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112008-08-27T22:37:03ZRuby Issue Tracking SystemRuby master - Feature #474: Hash#<<https://bugs.ruby-lang.org/issues/474?journal_id=9172008-08-27T22:37:03Zcandlerb (Brian Candler)b.candler@pobox.com
<ul></ul><p>=begin</p>
<blockquote>
<p>module Enumerable</p>
<pre><code>def map(&block)
o = self.class.new
each do |e|
o << yield(e)
end
o
end
</code></pre>
<p>end</p>
</blockquote>
<p>But that breaks a lot of useful stuff. e.g.</p>
<pre><code>a = File.open("/etc/passwd") { |f| f.map { |line| line.split(':') } }
</code></pre>
<p>or</p>
<pre><code>str = File.read("/etc/passwd")
a = str.map { |line| line.split(':') }
</code></pre>
<p>That is: the contract for map is to run through an Enumerable and build the<br>
results into an Array. It is not intended to run through an Enumerable and<br>
to append the results into a new instance of whatever class that object<br>
originally was.</p>
<p>It may not even be possible to create a new instance of that class, if the<br>
initialize method requires arguments.</p>
<p>Aside: I suppose you could have such a pattern if you explicitly provided<br>
the object to append to.</p>
<p>module Enumerable<br>
def into(target=[], &blk)<br>
blk ||= lambda { |e| e }<br>
each { |e| target << blk[e] }<br>
target<br>
end<br>
end</p>
<p>src = "one\ntwo\nthree\n"<br>
p src.into([])<br>
p src.into("") { |e| "*#{e}" }<br>
src.into($stdout) { |e| e.upcase } # process a line at a time</p>
<p>data = ["one\n", "two\n", "three\n"]<br>
p data.into("")</p>
<p>Perhaps even map itself could take the thing to write 'into' as an argument.</p>
<p>You could also argue that Hash#update should accept any Enumerable as its<br>
argument, so you could write</p>
<p>a = [[1,:one], [2,:two], [3,:three]]<br>
h = {}.update(a)</p>
<p>to convert an associative array to a hash.</p>
<p>But I've never needed either construct. Probably these things belong in the<br>
Facets library, if not there already. There is value in minimising the<br>
amount of magic in the core language, and there's a lot there already.</p>
<p>B.</p>
<p>=end</p> Ruby master - Feature #474: Hash#<<https://bugs.ruby-lang.org/issues/474?journal_id=9392008-08-28T18:17:06Zcandlerb (Brian Candler)b.candler@pobox.com
<ul></ul><p>=begin</p>
<blockquote>
<p>Not this case. String is no longer Enumerable.</p>
</blockquote>
<p>Thank you, my mistake. I'm not chasing the moving target of 1.9 until it<br>
stabilises. And even then I suspect I'll stick with 1.8.6 for quite a while,<br>
rather than learn new new magic and syntax in 1.9/2.0.</p>
<p>Now if 1.9 had <em>removed</em> magic or syntax from 1.8, I'd be much more<br>
interested. (For example, if it had eliminated the semantic distinctions<br>
between method calls, lambda calls and Proc calls). Then I could garbage<br>
collect some space in my brain.</p>
<p>But I guess that's an admission that I'm not qualified to talk on ruby-core,<br>
so I'll shut up now :-)</p>
<p>Cheers,</p>
<p>Brian.</p>
<p>=end</p> Ruby master - Feature #474: Hash#<<https://bugs.ruby-lang.org/issues/474?journal_id=9692008-09-01T17:27:51Zcandlerb (Brian Candler)b.candler@pobox.com
<ul></ul><p>=begin</p>
<blockquote>
<p>If you are a well practiced user of Ruby, I think that qualifies you.</p>
</blockquote>
<p>Thank you. What I meant was, I can hardly comment on core development (1.9)<br>
if I've been studiously avoiding it in favour of 1.8.</p>
<p>=end</p> Ruby master - Feature #474: Hash#<<https://bugs.ruby-lang.org/issues/474?journal_id=9882008-09-03T18:54:59Zko1 (Koichi Sasada)
<ul><li><strong>Assignee</strong> set to <i>matz (Yukihiro Matsumoto)</i></li></ul><p>=begin</p>
<p>=end</p> Ruby master - Feature #474: Hash#<<https://bugs.ruby-lang.org/issues/474?journal_id=12872008-10-02T17:44:27Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>=begin<br>
The usefulness and detailed behavior of the proposal is not cleared.<br>
So we have to reject this proposal this time. Maybe next time.<br>
=end</p> Ruby master - Feature #474: Hash#<<https://bugs.ruby-lang.org/issues/474?journal_id=18852008-12-08T15:35:01Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>=begin<br>
Hi,</p>
<p>In message "Re: <a href="/issues/474">[ruby-core:18370]</a> [Feature <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Hash#<< (Rejected)" href="https://bugs.ruby-lang.org/issues/474">#474</a>] Hash#<<"<br>
on Sat, 23 Aug 2008 05:35:06 +0900, Anonymous <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> writes:</p>
<p>|To recap, the idea is:<br>
|<br>
| h = Hash.new<br>
| h << [:a, 1]<br>
| h << [:b, 2]<br>
| h #=> {:a=>1, :b=>2}<br>
|<br>
|This creates a polymorphism between associative arrays and hashes, which ultimately could be useful to mixins. And now that Hash supports insertion order too, it makes further sense. There was a particular usecase exemplified in the fore-mentioned thread. But since I can't find it I can't show it here. I just recall thinking it was compelling. Perhaps other's can recall?</p>
<p>Unlike Smalltalk's Dictionaries, Hashes in Ruby does not provide the<br>
illusion of being sequence of association. So the proposed new method<br>
makes less sense in Ruby.</p>
<p>Besides that, Associative Arrays (which has normal array methods) and<br>
hashes cannot behave polymorphic.</p>
<pre><code> matz.
</code></pre>
<p>=end</p>