Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > '=||'

Reply
Thread Tools

'=||'

 
 
James Byrne
Guest
Posts: n/a
 
      05-05-2009
Can someone point out to me where exactly in the API I find a discussion
of the '=||' operator? Or am I imagining things and this does not
really exist?
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Eleanor McHugh
Guest
Posts: n/a
 
      05-05-2009
On 5 May 2009, at 20:51, James Byrne wrote:
> Can someone point out to me where exactly in the API I find a
> discussion
> of the '=||' operator? Or am I imagining things and this does not
> really exist?



Are you referring to ||= ? If so it's one of the augmented assignment
operators so you won't find it documented separately as it's syntactic
sugar for:

x = x || some_other_value


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason



 
Reply With Quote
 
 
 
 
James Byrne
Guest
Posts: n/a
 
      05-05-2009
James Byrne wrote:
> Or am I imagining things and this does not really exist?


Maybe I should look for '||=' instead. Sorry.

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Joe Gutierrez
Guest
Posts: n/a
 
      05-05-2009
Here's a link for Ruby's operator expressions

http://phrogz.net/ProgrammingRuby/language.html

Joseph Gutierrez
Web Developer - Inc21
http://www.velocityreviews.com/forums/(E-Mail Removed)



Eleanor McHugh wrote:
> On 5 May 2009, at 20:51, James Byrne wrote:
>> Can someone point out to me where exactly in the API I find a discussion
>> of the '=||' operator? Or am I imagining things and this does not
>> really exist?

>
>
> Are you referring to ||= ? If so it's one of the augmented assignment
> operators so you won't find it documented separately as it's syntactic
> sugar for:
>
> x = x || some_other_value
>
>
> Ellie
>
> Eleanor McHugh
> Games With Brains
> http://slides.games-with-brains.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason
>
>
>
>


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


 
Reply With Quote
 
7stud --
Guest
Posts: n/a
 
      05-05-2009
Eleanor McHugh wrote:
> Are you referring to ||= ? If so it's one of the augmented assignment
> operators so you won't find it documented separately as it's syntactic
> sugar for:
>
> x = x || some_other_value
>
>


Nope.

h = Hash.new(10)

h["red"] = h["red"] || 20

--output:--
{"red"=>10}


h = Hash.new(10)
h["blue"] ||= 20
p h

--output:--
{}


The statement:

x ||= val

is actually equivalent to:

x = val unless x

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Eleanor McHugh
Guest
Posts: n/a
 
      05-06-2009
On 6 May 2009, at 00:09, 7stud -- wrote:
> Eleanor McHugh wrote:
>> Are you referring to ||= ? If so it's one of the augmented assignment
>> operators so you won't find it documented separately as it's
>> syntactic
>> sugar for:
>>
>> x = x || some_other_value

>
> Nope.
>
> h = Hash.new(10)
>
> h["red"] = h["red"] || 20
>
> --output:--
> {"red"=>10}
>
>
> h = Hash.new(10)
> h["blue"] ||= 20
> p h
>
> --output:--
> {}
>
>
> The statement:
>
> x ||= val
>
> is actually equivalent to:
>
> x = val unless x



It seems you've misunderstood what happens under the hood when using
augmented assignment with tables as '||=' then becomes syntactic sugar
for 'x[] = x[] || some_other_value' and the assignment is performed
via '[]=' rather than '='. '[]=' will not create a key if it believes
it already exists and this is the cause of the behaviour you're seeing.

h = Hash.new(10)
p h["blue"] => 10
h["blue"] ||= 20
p h => {}

In this case when '||=' invokes the assignment it finds that h["blue"]
already contains a value because of the default so the hash method
'[]=' doesn't attempt to create a new key because it appears that the
key already exists.

Contrast this to:

h = Hash.new(10)
p h["blue"] => 10
h["blue"] = nil
p h => { "blue" => nil }
h["blue"] ||= 10
p h => { "blue" => 10 }
h["blue"] ||= 20
p h => { "blue" => 10 }

Here the key has been explicitly set equal to nil and '||=' acts the
way we'd expect an augmented assignment to work with scalar types.

Finally if no default is set for the table:

h = {}
h["red"] ||= 10
p h => {"red" => 10}

The key is always created as expected.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason



 
Reply With Quote
 
Rick DeNatale
Guest
Posts: n/a
 
      05-06-2009
On Tue, May 5, 2009 at 8:45 PM, Eleanor McHugh
<(E-Mail Removed)> wrote:
> On 6 May 2009, at 00:09, 7stud -- wrote:
>>
>> Eleanor McHugh wrote:
>>>
>>> Are you referring to ||= ? If so it's one of the augmented assignment
>>> operators so you won't find it documented separately as it's syntactic
>>> sugar for:
>>>
>>> x = x || some_other_value

>>
>> Nope.

...
>> The statement:
>>
>> x ||= val
>>
>> is actually equivalent to:
>>
>> x = val unless x

>
>
> It seems you've misunderstood what happens under the hood when using
> augmented assignment with tables as '||=' then becomes syntactic sugar for
> 'x[] = x[] || some_other_value' and the assignment is performed via '[]='
> rather than '='. '[]=' will not create a key if it believes it already
> exists and this is the cause of the behaviour you're seeing.


No, if x is truthy then

x ||= expression

will NOT do any assignment.

The real equivalent to x ||= y

is

x || x = y

The assignment is short-circuited.

For the proof see:

http://talklikeaduck.denhaven2.com/2008/04/26/x-y-redux


--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/pers...-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 
Reply With Quote
 
7stud --
Guest
Posts: n/a
 
      05-06-2009
Eleanor McHugh wrote:
> On 6 May 2009, at 00:09, 7stud -- wrote:
>> h = Hash.new(10)
>>
>> x = val unless x

> It seems you've misunderstood what happens under the hood when using
> augmented assignment with tables as '||=' then becomes syntactic sugar
> for 'x[] = x[] || some_other_value' and the assignment is performed
> via '[]=' rather than '='. '[]=' will not create a key if it believes
> it already exists and this is the cause of the behaviour you're seeing.
>
> h = Hash.new(10)
> p h["blue"] => 10
> h["blue"] ||= 20
> p h => {}
>
> In this case when '||=' invokes the assignment it finds that h["blue"]
> already contains a value because of the default so the hash method
> '[]=' doesn't attempt to create a new key because it appears that the
> key already exists.
>
> Contrast this to:
>
> h = Hash.new(10)
> p h["blue"] => 10
> h["blue"] = nil
> p h => { "blue" => nil }
> h["blue"] ||= 10
> p h => { "blue" => 10 }
> h["blue"] ||= 20
> p h => { "blue" => 10 }
>
> Here the key has been explicitly set equal to nil and '||=' acts the
> way we'd expect an augmented assignment to work with scalar types.
>
> Finally if no default is set for the table:
>
> h = {}
> h["red"] ||= 10
> p h => {"red" => 10}
>
> The key is always created as expected.
>



Why do I need to care about what's going on under the hood? If two
things
produce different results, then how can one be considered syntactic
sugar for the other. In my opinion, "syntactic sugar" means that the
two formats can
be used interchangeably--with experienced programmers naturally
gravitating to the shorter, easier to type format, and inexperienced
programmers preferring the longer, but easier to understand format.

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Eleanor McHugh
Guest
Posts: n/a
 
      05-06-2009
On 6 May 2009, at 02:38, 7stud -- wrote:
> Why do I need to care about what's going on under the hood?


Because when things don't work the way you expect, looking under the
hood allows you to adjust your expectations

> If two
> things
> produce different results, then how can one be considered syntactic
> sugar for the other. In my opinion, "syntactic sugar" means that the
> two formats can
> be used interchangeably--with experienced programmers naturally
> gravitating to the shorter, easier to type format, and inexperienced
> programmers preferring the longer, but easier to understand format.


All that syntactic sugar means is that one phrase is equivalent to
another syntactically, not that they're semantically equivalent.
However in the case of 'x = x || y' and 'x[n] = x[n] || y' are they
even syntactically equivalent? No. They appear syntactically similar,
but one invokes the '=' assignment operator whereas the other sends
the '[]=' message to the receiver. And because '[]=' leaves the
semantics of assignment to the receiver, that allows for the
differences you're seeing in this case.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason



 
Reply With Quote
 
Eleanor McHugh
Guest
Posts: n/a
 
      05-06-2009
On 6 May 2009, at 02:31, Rick DeNatale wrote:
> On Tue, May 5, 2009 at 8:45 PM, Eleanor McHugh
> <(E-Mail Removed)> wrote:
>> On 6 May 2009, at 00:09, 7stud -- wrote:
>>> The statement:
>>>
>>> x ||= val
>>>
>>> is actually equivalent to:
>>>
>>> x = val unless x

>>
>>
>> It seems you've misunderstood what happens under the hood when using
>> augmented assignment with tables as '||=' then becomes syntactic
>> sugar for
>> 'x[] = x[] || some_other_value' and the assignment is performed via
>> '[]='
>> rather than '='. '[]=' will not create a key if it believes it
>> already
>> exists and this is the cause of the behaviour you're seeing.

>
> No, if x is truthy then
>
> x ||= expression
>
> will NOT do any assignment.
>
> The real equivalent to x ||= y
>
> is
>
> x || x = y
>
> The assignment is short-circuited.
>
> For the proof see:
>
> http://talklikeaduck.denhaven2.com/2008/04/26/x-y-redux


Yes, for assignment that's the case. But 'x[n] ||= y' isn't an
instance of assignment in that case as can easily be demonstrated:

class Test
def method_missing symbol, *args
puts "calling method #{symbol}"
end
end

t = Test.new
t[:a] ||= 17

output: calling method []
calling method []=

Notice how even though method_missing returns a value and is thus
'true' the sequence still attempts all parts of the expression, and

t[:a] = t[:a] || 17

output: calling method []
calling method []=
=> 17

confirms that no short-circuited evaluation occurs.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments