From: dblack@...
Date: 2007-09-07T22:08:39+09:00
Subject: Re: assigning to hash keys when there is a default value?

Hi --

On Fri, 7 Sep 2007, Robert Klemme wrote:

> On 05.09.2007 00:15, dblack@wobblini.net wrote:
>> 
>> That one I didn't get wrong :-) I didn't say that retrieving the
>> default value creates a key (which it doesn't, since the default
>> value, whether nil or what you set it to, is specifically the default
>> value for keys that don't exist). My point was that this:
>>
>>   h = Hash.new(1)
>>   h[5] ||= 10
>> 
>> does not map to "x = x", assuming that x stands for h[5]. h[5] = h[5]
>> *does* set a key; as I said, it would set the 5 key to 1.  In fact
>> this whole thread is really about the fact that hash defaults, which
>> don't set keys, can be true, which short-circuits the ||= thing. I do
>> think it's the only such case, and probably fairly edge, though
>> obviously I'd like to see it do otherwise.
>
> I believe it's not the only case.  Although x= and []= are different, it 
> seems in *both* cases assignment is not even invoked for ||=:

True, but by "only *such* case" I meant: only case where evaluating
the lhs and getting true doesn't tell the whole story, in terms of the
functionality of the object, because of the defaulting to a value in
the absence of a key.

I suppose one could argue that it isn't ||='s problem if the lhs is
actually a kind of proxy. Nothing has yet convinced me, though, that
||= should not behave like x = x || y, even if the actual assignment
gets optimized away.


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)