Hi --

On Fri, 7 Sep 2007, Robert Klemme wrote:

> 2007/9/7, dblack / wobblini.net <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)