Please explain nuances of ||=
Ruby Freak
method used a lot.
knowing ruby the way I do, I realize that she has lots of magical
surprises and I really want to get to know this girl!
Consider the initialize method of resources.rb
51 def initialize(entities, options)
52 @plural ||= entities
53 @singular ||= options[:singular] ||
plural.to_s.singularize
54 @path_segment = options.delete(:as) || @plural
55
56 @options = options
57
58 arrange_actions
59 add_default_actions
60 set_prefixes
61 end
(OK, so one iddy bitty part of this is a rails question, and dangit,
this is a ruby forum, but you guys are smarter and have better
haircuts)
Question (1)
After several hours of searching I find virtually nothing that fully
explains the line
@singular ||= options[:singular] || plural.to_s.singularize
I think know what is does, It assigns @singular a value for a
"singular named" controller if the options hash contains the
symbol :singular. I am looking more for a full description of how ||=
and it's friends like &&= actually work.
my current understanding shows me:
@singular = (options[:singular]) or (plural.to_s.singularize)
but the full logic seems to be more like:
if options contains a symbol named :singular then
@singular = plural.to_s.singularize
end if
But what is the value of @singular if there is no :singular symbol?
nil?
What I think is going on is a lot more like an IF statement than a OR
statement.
Question (2)
in the line: @plural ||= entities
if entities is (false?, nil? something that fails "OR") what happens
to @plural?
Once again, the ||= seems more like an "equals If" statement rather
than an "equals Or" statement.
Question (3)
@path_segment = options.delete(:as) || @plural
So @path_segment is assigned either the return from the delete
operation (:as) ? or the plural name of the controller. Is that
correct? Where in a common resourceful routes mapping is there an :as?
Thanks in advance for any help.
Jeremy Henty
> I am reading some of the ruby files in rails and I an seeing the ||=
> method used a lot.
There's a nice discussion at
<URL:http://talklikeaduck.denhaven2.com/articles/2008/04/26/x-y-redux>.
Regards,
Jeremy Henty
Kyle Schmitt
@plural||=entries
simply says, if @plural is nil or false (someone correct me if I'm a
tad off), set it to entries, otherwise don't do anything.
For @singular, close but.. you need the or
@singular ||= ((options[:singular]) or (plural.to_s.singularize))
@path_segment is a little bit stranger, but for me it harkens back to c days.
if options.delete(:as) returns any value that evalutes to true
(anything but nil or false), @path_segment is set to that value. If
options.delete(:as) fails or returns nil, @path_segment is set to
@plural.
Does that help?
David A. Black
On Fri, 2 May 2008, Ruby Freak wrote:
> I am reading some of the ruby files in rails and I an seeing the ||=
> method used a lot.
> knowing ruby the way I do, I realize that she has lots of magical
> surprises and I really want to get to know this girl!
x ||= y means: x || x = y
The difference is that x ||= y won't complain if x is undefined,
whereas if you type x || x = y and there's no x in scope, it will. The
basic idea is that if x is (a) undefined (b) nil (c) false, you want
to set it to y. Otherwise, you want to leave it alone. The whole
expression evaluates to x, after the assignment has happened (or not).
See http://dablog.rubypal.com/2008/3/25/a-short-circuit-edge-case for
more.
David
--
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
INTRO TO RAILS June 24-27 London (Skills Matter)
See http://www.rubypal.com for details and updates!
Ruby Freak
Yes, Thank you,
That is very helpful.
Google seems to puke on "||=" so I wasn't getting any search results.
Simon Krahnke
> Hi --
>
> On Fri, 2 May 2008, Ruby Freak wrote:
>
>> I am reading some of the ruby files in rails and I an seeing the ||=
>> method used a lot.
>> knowing ruby the way I do, I realize that she has lots of magical
>> surprises and I really want to get to know this girl!
>
> x ||= y means: x || x = y
No, it means: x = x || y
> The difference is that x ||= y won't complain if x is undefined,
That's because = does the same.
mfg, simon .... l
Robert Klemme
> * David A. Black <dbl...@rubypal.com> (18:56) schrieb:
>
>> Hi --
>>
>> On Fri, 2 May 2008, Ruby Freak wrote:
>>
>>> I am reading some of the ruby files in rails and I an seeing the ||=
>>> method used a lot.
>>> knowing ruby the way I do, I realize that she has lots of magical
>>> surprises and I really want to get to know this girl!
>> x ||= y means: x || x = y
>
> No, it means: x = x || y
I believe you are wrong.
irb(main):001:0> h={}
=> {}
irb(main):002:0> h=Hash.new true
=> {}
irb(main):003:0> h[1]
=> true
irb(main):004:0> h[1] ||= 10
=> true
irb(main):005:0> h
=> {}
irb(main):006:0>
If you were right, h would look differently:
irb(main):008:0> h=Hash.new true
=> {}
irb(main):009:0> h[1] = h[1] || 10
=> true
irb(main):010:0> h
=> {1=>true}
The same topic has been discussed exhaustively a few days ago.
Cheers
robert
David A. Black
On Fri, 2 May 2008, Simon Krahnke wrote:
> * David A. Black <dbl...@rubypal.com> (18:56) schrieb:
>
>> Hi --
>>
>> On Fri, 2 May 2008, Ruby Freak wrote:
>>
>>> I am reading some of the ruby files in rails and I an seeing the ||=
>>> method used a lot.
>>> knowing ruby the way I do, I realize that she has lots of magical
>>> surprises and I really want to get to know this girl!
>>
>> x ||= y means: x || x = y
>
> No, it means: x = x || y
This is becoming a bit of a perma-thread :-)
See Robert K.'s answer, and also have a look at the blog post I
mentioned in my response. It's about exactly why x = x || y is not the
right expansion for x ||= y.
Phillip Gawlowski
Hash: SHA1
You are wrong, too, though.
I refer you to Ruby-Talk 297145[0]:
Quoth Joshua Ballanco:
'The only reason that Chris' example behaves like "x || x = stuff" is
because he's defined a default value for the hash. If you set a default
value, than you'll never have a keyed value be empty (i.e. nil). '
x = x || 'a value' works when x is nil or false. Once the Hash has a
default value, it shouldn't be false, much less nil.
See:
irb(main):001:0> h = Hash.new
=> {}
irb(main):002:0> h[1].nil?
=> true
irb(main):003:0> h[1] = h[1] || 10
=> 10
irb(main):004:0> h[2] = 'not nil'
=> "not nil"
irb(main):005:0> h[2] = h[2] || 'a value'
=> "not nil"
irb(main):006:0> h[3] = false
=> false
irb(main):007:0> h[3] = h[3] || 'not false'
=> "not false"
[0] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/297145
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ Calvin: I'm a genius, but I'm a misunderstood genius. Hobbes: What's
misunderstood about you? Calvin: Nobody thinks I'm a genius. -- Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgaJxMACgkQbtAgaoJTgL8e0QCdHbW1PniEGPZSlC9Api4lIL7u
viAAnis9nThp0JAXQEwGWU+JEM5s+ssL
=3HqG
-----END PGP SIGNATURE-----
Phillip Gawlowski
Hash: SHA1
David A. Black wrote:
|> No, it means: x = x || y
|
| This is becoming a bit of a perma-thread :-)
|
| See Robert K.'s answer, and also have a look at the blog post I
| mentioned in my response. It's about exactly why x = x || y is not the
| right expansion for x ||= y.
x ||= y expands into x = x || y, since x == 1 expands to x = x + 1, and
we have no reason to expect ||= to behave differently (MPLOS).
Also, it works as expected if the expansion x = x || y is correct. After
all:
'The or and || operators evaluate their first operand. If true, the
expression returns the value of their first operand; otherwise, the
expression returns the value of the second operand.'
Programming Ruby, 2nd Edition (p. 326).
And Robert's answer works the way it works because the Hash has a
default value set, which doesn't equate to false or nil. If you override
the default value by setting the value to false, the assignment works
again as expected.
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
Zero raised to the nth power remains zero.
~ -- Pop Baslim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgaKhoACgkQbtAgaoJTgL/LkgCeMqByMe50+mJx/j8vV3KC612p
lF4AnAz+GVlTLKNPdcjZnsFbbTTwHebv
=Tkje
-----END PGP SIGNATURE-----
David A. Black
The question, though, is what x ||= y expands to. Robert's point is
that if you say it expands to x = x || y, that doesn't account for
what happens with a hash that has a non-false default value.
Mind you, x || x = y doesn't account (as I mentioned) for the fact
that if x isn't defined, you can't use that syntax. x ||= y is really
its own thing, and doesn't expand 100% of the time to anything. But x
|| x = y, if you allow for the undefined x thing, describes all of the
behaviors, including the hash edge case.
Ruby Freak
surprises and I really want to get to know this girl!
Happens every time! Bring a girl into the bar and a fight breaks out.
David A. Black
On Fri, 2 May 2008, Phillip Gawlowski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David A. Black wrote:
>
> |> No, it means: x = x || y
> |
> | This is becoming a bit of a perma-thread :-)
> |
> | See Robert K.'s answer, and also have a look at the blog post I
> | mentioned in my response. It's about exactly why x = x || y is not the
> | right expansion for x ||= y.
>
>
> x ||= y expands into x = x || y, since x == 1 expands to x = x + 1, and
I think you mean +=.
> we have no reason to expect ||= to behave differently (MPLOS).
That's really where this thread always starts, though: why doesn't it
behave like x = x || y in every case? Anyway, the thing about MPOLS is
that you and I can't invoke it :-) It was actually Matz who showed me
the x || x = y expansion (most recently at EuRuKo, where I talked to
him about it because I wanted to make sure the corrections I made to
my blog post had made it correct).
> Also, it works as expected if the expansion x = x || y is correct. After
> all:
>
> 'The or and || operators evaluate their first operand. If true, the
> expression returns the value of their first operand; otherwise, the
> expression returns the value of the second operand.'
> Programming Ruby, 2nd Edition (p. 326).
>
> And Robert's answer works the way it works because the Hash has a
> default value set, which doesn't equate to false or nil. If you override
> the default value by setting the value to false, the assignment works
> again as expected.
Right, but hashes are allowed to have default values. So an
explanation that accounts for that case is better than one that
doesn't. The point is that if you do a drop-in replacement x = x || y
you get a different result from ||=, and with x || x = y you don't.
That means, definitively I think, that the latter is a more correct
expansion. (I'm not sure how it couldn't mean that.)
Anyway, this is at least the third thread on this in recent months,
and I've written my blog post (and correction follow-up :-) about it.
I think I'm about ||='d out.
Phillip Gawlowski
Hash: SHA1
David A. Black wrote:
|> x ||= y expands into x = x || y, since x == 1 expands to x = x + 1, and
|
| I think you mean +=.
Yes, indeed.
|> we have no reason to expect ||= to behave differently (MPLOS).
|
| That's really where this thread always starts, though: why doesn't it
| behave like x = x || y in every case? Anyway, the thing about MPOLS is
| that you and I can't invoke it :-) It was actually Matz who showed me
| the x || x = y expansion (most recently at EuRuKo, where I talked to
| him about it because I wanted to make sure the corrections I made to
| my blog post had made it correct).
It doesn't behave that way because classes can implement and override
behavior. Which can lead to surprising results, and sometimes
pathological cases of Monkeypatching. ;)
Also, the MPLOS helps as a guideline, not as a hard and fast rule. :)
|> And Robert's answer works the way it works because the Hash has a
|> default value set, which doesn't equate to false or nil. If you override
|> the default value by setting the value to false, the assignment works
|> again as expected.
|
| Right, but hashes are allowed to have default values. So an
| explanation that accounts for that case is better than one that
| doesn't. The point is that if you do a drop-in replacement x = x || y
| you get a different result from ||=, and with x || x = y you don't.
| That means, definitively I think, that the latter is a more correct
| expansion. (I'm not sure how it couldn't mean that.)
However, a default value results in the Hash not evaluating to nil or
false. Which is required for || and OR to use their *second* operand
(since it otherwise uses the first operand), so x || x = y cannot work.
Unless we get into precedence issues here, I guess.
| Anyway, this is at least the third thread on this in recent months,
| and I've written my blog post (and correction follow-up :-) about it.
| I think I'm about ||='d out.
So am I.
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ Why do we drink cow's milk? Who was the first guy who first looked at
a cow and said "I think I'll drink whatever comes out of these things
when I squeeze 'em!"? -- Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgaMdsACgkQbtAgaoJTgL+7ggCfZvH1Zt26JJtfKA+uPdd28oPV
/28AnjWINp8XwuVrx00X2qRT/LCtz/Ny
=CldW
-----END PGP SIGNATURE-----
David A. Black
On Fri, 2 May 2008, Phillip Gawlowski wrote:
> However, a default value results in the Hash not evaluating to nil or
> false. Which is required for || and OR to use their *second* operand
> (since it otherwise uses the first operand), so x || x = y cannot work.
> Unless we get into precedence issues here, I guess.
It depends what you mean by work :-) See Robert's example.
> | Anyway, this is at least the third thread on this in recent months,
> | and I've written my blog post (and correction follow-up :-) about it.
> | I think I'm about ||='d out.
>
> So am I.
Whoops -- sorry :-)
I actually have a feeling we're talking at cross-purposes, and that
I'm somehow not getting something. All I'm saying is that h[x] ||=
value is the same as h[x] || h[x] = value, for any hash h and any key
x. That can be demonstrated easily (as Robert did) just by
substituting one expression for the other. It's an unusual case, but
it's legal. I'm not sure what would be needed beyond that to
demonstrate that x = x || y is not a drop-in replacement for x ||= y.
Phillip Gawlowski
Hash: SHA1
David A. Black wrote:
| Hi --
|
| On Fri, 2 May 2008, Phillip Gawlowski wrote:
|
| Whoops -- sorry :-)
As if. :P
| I actually have a feeling we're talking at cross-purposes, and that
| I'm somehow not getting something. All I'm saying is that h[x] ||=
| value is the same as h[x] || h[x] = value, for any hash h and any key
| x. That can be demonstrated easily (as Robert did) just by
| substituting one expression for the other. It's an unusual case, but
| it's legal. I'm not sure what would be needed beyond that to
| demonstrate that x = x || y is not a drop-in replacement for x ||= y.
Yeah, I'm taking the Bird's Eye View on it all, essentially saying: 'it
works like this almost always, but Hash is a special case, since it has
default values [or whatever the implementation detail is, that makes
Hash work differently]).
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ "Endorsing products is the American way of expressing individuality."
- -Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgaPUgACgkQbtAgaoJTgL/kQQCggPuXLrZqT/zmBBALUKUY1/4h
P44An2JhhO4GiMgkGP07DULeaV5d5a+u
=nH6/
-----END PGP SIGNATURE-----
David A. Black
On Fri, 2 May 2008, Phillip Gawlowski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David A. Black wrote:
> | Hi --
> |
> | On Fri, 2 May 2008, Phillip Gawlowski wrote:
> |
> | Whoops -- sorry :-)
>
> As if. :P
>
> | I actually have a feeling we're talking at cross-purposes, and that
> | I'm somehow not getting something. All I'm saying is that h[x] ||=
> | value is the same as h[x] || h[x] = value, for any hash h and any key
> | x. That can be demonstrated easily (as Robert did) just by
> | substituting one expression for the other. It's an unusual case, but
> | it's legal. I'm not sure what would be needed beyond that to
> | demonstrate that x = x || y is not a drop-in replacement for x ||= y.
>
> Yeah, I'm taking the Bird's Eye View on it all, essentially saying: 'it
> works like this almost always, but Hash is a special case, since it has
> default values [or whatever the implementation detail is, that makes
> Hash work differently]).
It's possible to generalize it; someone in one of the threads wrote a
class that showed the same behavior, but I can't remember the details.
I do wish it were otherwise; it's definitely unexpected, I think.
Phillip Gawlowski
Hash: SHA1
David A. Black wrote:
| Hi --
|
| It's possible to generalize it; someone in one of the threads wrote a
| class that showed the same behavior, but I can't remember the details.
| I do wish it were otherwise; it's definitely unexpected, I think.
Well, it is unexpected if you forget about the default value for Hash,
for example.
So, I agree: On first sight it *is* unintuitive. Once you think about,
though..
As a tangent:
I've just checked my copy of The Ruby Way, and its 'Training your
intuition' sub-chapter. This gotcha isn't part of it. :(
Maybe it could be added for the next edition (unless Ruby 1.9/2.0 is the
reason for the new edition, and the ambiguity/idiosyncrasy is removed in
the new version of Ruby by then).
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ "Oops, I always forget the purpose of competition is to divide people
into
winners and losers." -Hobbes being sarcastic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgaSVoACgkQbtAgaoJTgL+ExwCgjbqnS7cqvvMHhPy5PRt8DX9Y
nOkAoJF5YjaZuXQA71NhvdpEe/9zlFdx
=sYWv
-----END PGP SIGNATURE-----
Kazuo Ishii
--
Kazuo Ishii Ph.D., Tokyo Univ. of Science
freep...@gmail.com
Joel VanderWerf
> It's possible to generalize it; someone in one of the threads wrote a
> class that showed the same behavior, but I can't remember the details.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/297185
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Rick DeNatale
this controversy:
http://talklikeaduck.denhaven2.com/articles/2008/04/26/x-y-redux
In writing this article, I pulled my old dusty copy of Kernighan and
Ritchie off my shelf, since IIRc the whole
x op= y
idea originally came from C.
And of course that's where the oft reported meme that
x op=y
was identical to
x = x op y
originated, and was propagated through several popular expositions of Ruby.
BUT
C, although it does have || and && as short-circuit boolean operators,
does NOT allow ||= or &&=
When Matz added these to Ruby he, quite cleverly IMHO, defined them as
short circuiting as well, the assignment is NOT done if the LHS
evaluates to true (in the Ruby sense that is, neither nil nor false).
And as I also verified, since reading about ||= in David Flanigan's
"The Ruby Programming Language" got me to thinking about it, &&= also
doesn't do an assignment if the LHS evaluates to false.
All of this falls out naturally from 1) short-circuit evaluation of ||
and &&, and 2) the fact that a.x = y is syntactic sugar for a.x=(y),
and 3) a[b] = c is syntactic sugar for a.[]=(b,c).
So a foolish adherence to the idea that Ruby should slavishly follow C
where ||= and &&= are not allowable assignment operators, and there
are no x= or []= methods to serve as targets of syntactic sugar,
doesnt make that sense.
So:
1) In Ruby x ||= y does no assignment if x evaluates to true, and x
&&= y does no assignment if x evaluates to true.
2) x || x = y, and x && x = y are much better first approximations of
how x ||= y and x &&= y than x = x || y, and x = x && y, despite what
K&R say.
3) I say first approximations because of David Black's observation
that x ||= y and x || x = y differ when x is undefined.
In summary:
That's the way that Ruby works. Ruby ain't C, or C++ or Java.
Get over it! <G>
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Robert Klemme
> So:
>
> 1) In Ruby x ||= y does no assignment if x evaluates to true, and x
> &&= y does no assignment if x evaluates to true.
> 2) x || x = y, and x && x = y are much better first approximations of
> how x ||= y and x &&= y than x = x || y, and x = x && y, despite what
> K&R say.
> 3) I say first approximations because of David Black's observation
> that x ||= y and x || x = y differ when x is undefined.
>
> In summary:
>
> That's the way that Ruby works. Ruby ain't C, or C++ or Java.
Nice summary! And, if you think about it from a usability perspective
it does make the most sense the way it is.
1. you do not want to spent CPU cycles for assigning the same object
to a reference
2. more importantly, in the case of Hash you do not want the Hash to
change (which it would do if ||= were implemented differently as I
have demonstrated earlier).
I'm out.
Cheers
robert
--
use.inject do |as, often| as.you_can - without end
Simon Krahnke
> 1) In Ruby x ||= y does no assignment if x evaluates to true, and x
> &&= y does no assignment if x evaluates to true.
Eh, what? You are confusing me.
&&= does an assignment only if x evaluates to true.
The question of if there is an assignment in x = x is purely
metaphysical: there is no way to tell.
> 2) x || x = y, and x && x = y are much better first approximations of
> how x ||= y and x &&= y than x = x || y, and x = x && y, despite what
> K&R say.
And doesn't explain why x springs into existence, if didn't exist
before.
> 3) I say first approximations because of David Black's observation
> that x ||= y and x || x = y differ when x is undefined.
Right, but x = x || y doesn't.
The only thing special about x ||= y is that x is only ever evaluated
once. But that's special in every op=.
mfg, simon .... l
Simon Krahnke
> irb(main):009:0> h[1] = h[1] || 10
> => true
Well, the difference is that h[1] gets only evaluated once.
But now I get it: It does make a difference here if there is an
assignment or not. So much for metaphysics. :-(
So, neither x = x || y nor x || x = y explain everything about x ||= y.
&&= and ||= are different from += and co, because of their short-cut
behavior. They are conditional assignment operators.
mfg, simon .... sfti
Rick DeNatale
> * Rick DeNatale <rick.d...@gmail.com> (03:26) schrieb:
>
>
> > 1) In Ruby x ||= y does no assignment if x evaluates to true, and x
> > &&= y does no assignment if x evaluates to true.
>
> Eh, what? You are confusing me.
>
> &&= does an assignment only if x evaluates to true.
Yes, that was a typo on my part, it should have read "and x &&= y
does not assignment if x evaluates to false."
> The question of if there is an assignment in x = x is purely
> metaphysical: there is no way to tell.
If x is a simple variable, that's correct, however if x is actually an
"attribute accessor" like
foo.bar ||= y
or
foo[:bar] ||= y
Then you can tell if the bar= or []= method which gets invoked on
'assignment' has side effects.
> > 2) x || x = y, and x && x = y are much better first approximations of
> > how x ||= y and x &&= y than x = x || y, and x = x && y, despite what
> > K&R say.
>
> And doesn't explain why x springs into existence, if didn't exist
> before.
This is because the Ruby parser recognizes the variable as local when
it sees it as the POTENTIAL assignee. In the first chunk below, the a
= 1 never got executed because of the if false modifier, but the
parser still picked up a 'declaration' of a as a local variable.
defined? a # => nil
a = 1 if false
defined? a # => "local-variable"
a # => nil
defined? b # => nil
b ||= 1
defined? b # => "local-variable"
b # => 1
defined? c # => nil
c &&= 1
defined? c # => "local-variable"
c # => nil
of course in the case of
d.e ||= g
or
h[1] ||= i
There's no question of the method 'springing' into existence, d.e,
d.e=, h[], and h[]= will either work or throw a method not found if
and when they are called.
> > 3) I say first approximations because of David Black's observation
> > that x ||= y and x || x = y differ when x is undefined.
>
> Right, but x = x || y doesn't.
>
> The only thing special about x ||= y is that x is only ever evaluated
> once. But that's special in every op=.
Except that, if x is really obj.foo, or obj[a] then the notion of x
getting evaluated once is a little squirrelly, because reading x is
done by evaluating obj.foo or obj.[](a), and writing it (should the
assignment actually occur) is done by evaluating obj.foo=(y) or
obj.[]=(a,y)
The fact that x = y is actually a method call under some circumstances
is what's special about Ruby, and why simply extending K&Rs
explanation of op= misses the point.
Pit Capitain
> 3) I say first approximations because of David Black's observation
> that x ||= y and x || x = y differ when x is undefined.
They obviously also differ if evaluating x has side effects as in
h = {}
h[print("f")] ||= 1
h = {}
h[print("o")] || h[print("o")] = 1
# => foo
so x ||= y is more like
ref = &x; *ref || *ref = y
with the reference (&) and dereference (*) operators of C.
Regards,
Pit
Rick DeNatale
But x is different whether its on the RHS or LHS
The problem is that it's not a textual substitution.
h[1+2] ||= 3 is like
arg_temp = 1 + 2
h[arg_temp] || h[arg_temp] = 3
Keep in mind that unlike operators like + and -, || and && are really
control flow 'operators' implemented by testing and branching. The
same is true of ||= and &&=, which I suppose is the point.
Ruby 1.9 makes it somewhat easier to see what's really happening.
k$ ruby1.9 -ve'puts VM::InstructionSequence.compile("h={};h[\"a\" +
\"b\"] ||= 3").disasm'
ruby 1.9.0 (2008-03-21 revision 0) [i686-darwin9.2.2]
== disasm: <ISeq:<compiled>@<compiled>>=================================
local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1] s1)
[ 2] h
0000 newhash 0 ( 1)
0002 setlocal h
0004 getlocal h
0006 putstring "a"
0008 putstring "b"
0010 opt_plus
0011 dupn 2
0013 opt_aref
0014 dup
0015 branchif 28
0017 pop
0018 putobject 3
0020 send :[]=, 2, nil, 0, <ic>
0026 leave
0027 pop
0028 swap
0029 pop
0030 swap
0031 pop
0032 leave
I'm sure that Ruby 1.8 does pretty much the same thing, but I don't
have the time to dig through parse.y and eval.c to prove it.
Simon Krahnke
> Ruby 1.9 makes it somewhat easier to see what's really happening.
Thanks a lot!
> k$ ruby1.9 -ve'puts VM::InstructionSequence.compile("h={};h[\"a\" +
> \"b\"] ||= 3").disasm'
Can you give any documentation pointers for this cool stuff?
mfg, simon .... l