From: dblack@... Date: 2007-09-07T22:52:17+09:00 Subject: Re: assigning to hash keys when there is a default value? Hi -- On Fri, 7 Sep 2007, Robert Klemme wrote: > 2007/9/7, dblack@wobblini.net : >>> 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. > > Ah, ok. Should've read more carefully. I am sorry. > >> 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. > > Umm, now I am confused. I thought the "optimized away" bit is the > critical bit - if you allow for this difference then they do actually > behave the same, don't they? That may be right. I guess I'm focusing on the visible behavior, and not the implementation, so I'm probably saying dumb things about the implementation. > Btw, here's a possible explanation why the behavior is the way it is: > []= and x= are usually costly operations (i.e. not just assignments > but methods doing some work) so avoiding that would help overall > performance. Still I believe that's probably better than the > consistency although I usually tend to favor consistency as well. That was Rick DeNatale's point too: that it could be expensive to call a =-method. I agree, though if x[1] ||= y were just sugar for x[1] = x[1] || y, then one could optimize it on the Ruby side with x[1] = y unless x[1]. Oh well. I don't think this is going to change, and at this point I should probably stop complaining unless I can come up with a new implementation :-) 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)