I read this once:
Operator ||= can be shorthand for code like:
x = “(some fallback value)” unless respond_to? :x or x
How would that look like exactly, in shorthand, any guesses?
-r
I read this once:
Operator ||= can be shorthand for code like:
x = “(some fallback value)” unless respond_to? :x or x
How would that look like exactly, in shorthand, any guesses?
-r
Roger P. wrote:
I read this once:
Operator ||= can be shorthand for code like:
x = “(some fallback value)” unless respond_to? :x or xHow would that look like exactly, in shorthand, any guesses?
foo ||= 5
is shorthand for
foo = foo || 5
which means
(a) ‘foo’ is a local variable (because it’s an assignment)
(b) it will be set to 5 if it is currently nil or false, otherwise it
will retain its previous value.
The thing you read about respond_to? is wrong. This construct is nothing
to do with a method called foo, as you can easily demonstrate:
$ irb --simple-prompt
def foo
9
end
=> nilrespond_to? :foo
=> truefoo ||= 5
=> 5foo
=> 5
On 2010-06-14 14:48:36 -0700, Roger P. said:
I read this once:
Operator ||= can be shorthand for code like:
x = “(some fallback value)” unless respond_to? :x or xHow would that look like exactly, in shorthand, any guesses?
-r
The expression:
a ||= b
is equivalent to:
a || a = b
in most cases. To be pedantic, it is actually:
(defined?(a) && a) || a = b
and does not raise an error for undefined local variables. This is also
true of `&&=’.
Note:
The code:
x = “some value”
will always set the local variable x', whether there is a method
x’
on self or not, so your code that uses respond_to? will not behave as
you expect it to.
Another note:
the expression (in pseudocode):
a = b
is equivalent to:
a = a b
except where is || or &&, where the above applies.
Examples:
a = 1
a += 5
a *= 10
a # => 60
b = [:foo, :bar]
b |= [:bar, :bizz]
b # => [:foo, :bar, :bizz]
flag = 0b01
flag |= 0b10
flag.to_s(2) # => “11”
Roger P. [email protected] writes:
I read this once:
Operator ||= can be shorthand for code like:
x = “(some fallback value)” unless respond_to? :x or xHow would that look like exactly, in shorthand, any guesses?
-r
Sure you don’t mean ||= as a way of easily implementing basic
memoization?
Example:
class Foo
def bar
@bar ||= begin
# do some calculations here
1 + rand
end
end
end
f = Foo.new
f.bar # => 1.01853966346202
f.bar # => 1.01853966346202
On Mon, Jun 14, 2010 at 5:48 PM, Roger P. [email protected]
wrote:
I read this once:
Operator ||= can be shorthand for code like:
x = “(some fallback value)” unless respond_to? :x or xHow would that look like exactly, in shorthand, any guesses?
I don’t know where you read that, but it has no basis in reality. The
semantics of ||= have nothing to do with whether or not a method
exists.
The closest translation of
x ||= y
(x || x = y)
This is close, except that it will blow up if x isn’t already defined.
another alternative might be
(defined? x) ? (x || x = y) : y
Which avoids the problem when x isn’t defined, but isn’t exactly what
the ‘compiled’ ruby code does, whether that ‘code’ is YARV ‘byte
codes’ or an AST in MRI pre 1.9
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
On Mon, Jun 14, 2010 at 8:35 PM, Josh C. [email protected]
wrote:
codes’ or an AST in MRI pre 1.9
This implies to me that if x is not defined, then return y without modifying
x. But this contradicts the reason I used ||= for (lazy assignment).
Yeah it was a typo on my part
(defined? x) ? (x || x = y) : (x = y)
As I said before though, all of these are approximations. The
defined? guard is just to avoid the undefined variable error.
For
x ||= y
The compiler defines x when it sees it, normally a local variable only
gets defined when it actually gets a value assigned.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
On Tue, Jun 15, 2010 at 1:24 PM, Brian C. [email protected]
wrote:
foo ||= 5
is shorthand for
foo = foo || 5
NO it is NOT, although many Rubyist seem to cling to this idea.
see http://talklikeaduck.denhaven2.com/2008/04/26/x-y-redux
and recent discussion on this very thread.
The difference between
x ||= 5
and
x = x | | 5
is that if x has a truthy value, then NO assignment will be done in
the first case (including assignment through a ‘setter’ method) in the
first case, but it will in the second.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
On 6/14/10, Rein H. [email protected] wrote:
The expression:
a ||= b
is equivalent to:
a || a = b
in most cases. To be pedantic, it is actually:
(defined?(a) && a) || a = b
Except if there’s a method named a, defined?(a) returns “method”, so
this still isn’t exactly equivalent. Ruby is tricksy.
On 2010-06-14 15:41:09 -0700, Rick DeNatale said:
semantics of ||= have nothing to do with whether or not a method
another alternative might be
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Rick,
Can we combine the contents of the thousands of messages explaining the
behavior of = into a blog post and just start referencing it?
Oh wait, didn’t you do that?
We need a FAQ
On 2010-06-14 17:21:00 -0700, Caleb C. said:
(defined?(a) && a) || a = b
Except if there’s a method named a, defined?(a) returns “method”, so
this still isn’t exactly equivalent. Ruby is tricksy.
Yes, thank you for your meta-pedantry
It is not actually implemented as such but the behavior is very similar.
Rick Denatale wrote:
The difference between
x ||= 5
and
x = x | | 5
is that if x has a truthy value, then NO assignment will be done in
the first case (including assignment through a ‘setter’ method) in the
first case, but it will in the second.
I never said that foo.x ||= 5 behaves like this. This is a method call
(:x=) not a local variable assignment.
class Foo
def initialize(x=nil)
self.x = x
end
def x
@x
end
def x=(x)
puts “set to #{x}”
@x = x
end
end
f = Foo.new
f.x ||= 3
f.x ||= 5
On Mon, Jun 14, 2010 at 5:41 PM, Rick DeNatale
[email protected]wrote:
This implies to me that if x is not defined, then return y without
modifying
x. But this contradicts the reason I used ||= for (lazy assignment).
$ irb
ruby-1.9.1-p378 > defined? x
=> nil
ruby-1.9.1-p378 > defined? x
=> nil
ruby-1.9.1-p378 > x ||= 5
=> 5
ruby-1.9.1-p378 > x
=> 5
On Thu, Jun 17, 2010 at 11:07 AM, Brian C. [email protected]
wrote:
I never said that foo.x ||= 5 behaves like this. This is a method call
(:x=) not a local variable assignment.
No, but you said that “foo ||= 5 is shorthand for foo = foo || 5”
which implies the same semantics, but…
class Foo
def initialize(x=nil)
self.x = x
end
def x
@x
end
def x=(x)
puts “set to #{x}”
@x = x
end
end
f = Foo.new
f.x ||= 3
f.x ||= 5
f.x = f.x || 6
produces:
set to
set to 3
set to 3
See the difference?
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
2010/6/14 Roger P. [email protected]:
I read this once:
Operator ||= can be shorthand for code like:
x = “(some fallback value)” unless respond_to? :x or xHow would that look like exactly, in shorthand, any guesses?
You can do this:
x ||= (x() rescue “(some fallback value)”)
I did not think about this long enough to look at all the effects with
local variables shadowing methods but it’s something you can play
with.
Kind regards
robert
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs