Use of "return"

This is a total newbie question, but I’d like to know how “return” is
specifically used in ruby. From my understanding, it can be avoided in
a
lot of cases since ruby returns the last value by default.

However, some of the code in the Rails stuff I’m looking at has “return”
and
I was wondering if this “return” is necessary or just the individual
programmer’s style (maybe carried over from other languages).

Sorry, I’m vague but I would like to know how “return” is effectively
used
in ruby if at all.

Here’s a code snippet from the SaltedHash Engine

def new_security_token(hours = nil)
  write_attribute('security_token', AuthenticatedUser.hashed(

self.salted_password + Time.now.to_i.to_s + rand.to_s))
write_attribute(‘token_expiry’, Time.at(Time.now.to_i +
token_lifetime(hours)))
update_without_callbacks
return self.security_token
end

or this:

  def authenticate(login, pass)
    u = find(:first, :conditions => ["login = ? AND verified = 1 AND

deleted = 0", login])
return nil if u.nil?
find(:first, :conditions => [“login = ? AND salted_password = ?
AND
verified = 1”, login, AuthenticatedUser.salted_password(u.salt,
AuthenticatedUser.hashed(pass))])
end

Sorry if my question’s off the wall. Still finding my bearings.

Hi –

On Mon, 9 Jan 2006, SB wrote:

Here’s a code snippet from the SaltedHash Engine

def new_security_token(hours = nil)
write_attribute(‘security_token’, AuthenticatedUser.hashed(
self.salted_password + Time.now.to_i.to_s + rand.to_s))
write_attribute(‘token_expiry’, Time.at(Time.now.to_i +
token_lifetime(hours)))
update_without_callbacks
return self.security_token

Programmer’s individual style. You could replace that line with:

security_token

“self” as receiver would be implied, and since it’s the last
expression evaluated, it would be the return value of the method.

end

or this:

 def authenticate(login, pass)
   u = find(:first, :conditions => ["login = ? AND verified = 1 AND

deleted = 0", login])
return nil if u.nil?

A return in mid-method needs “return”. You could avoid it by
rewriting the end of the method like this:

if u.nil?
nil
else
other code
end

But the “return nil if u.nil?” thing both terminates the method and
provides a visual cue that u being nil is a terminal condition. So
it’s partly style, but once you decide to do a mid-method return, you
have to use “return”.

David


David A. Black
[email protected]

“Ruby for Rails”, from Manning Publications, coming April 2006!

hi,
‘return’ is used to return a value, and end the method processing.
at the end of a method, ‘return’ is indeed not needed, and simply that
value
will suffice, though i think a return looks nicer :wink:
a good example where a return is needed, is this:

def method(arg)
if arg.class==String
return “invalid argument”
end
#rest of processing
end

this looks a lot nicer than placing your entire method in if/else code.
greetings, Dirk.

[email protected] wrote:

I was wondering if this “return” is necessary or just the individual
write_attribute(‘security_token’, AuthenticatedUser.hashed(
“self” as receiver would be implied, and since it’s the last
return nil if u.nil?
But the “return nil if u.nil?” thing both terminates the method and
provides a visual cue that u being nil is a terminal condition. So
it’s partly style, but once you decide to do a mid-method return, you
have to use “return”.

David

“return” is required if you want to return multiple values like this:

def foo
return “a”, “b”, “c”
end

Though you can also do this

def foo
[“a”, “b”, “c”]
end

Personally, I always use “return” if the name of the variable/method is
short.

Short names

return result
return value

Long name, no “return” keyword

Foo::Bar.bur(1, 2, 3)

Method call with arguments, no “return” keyword

foobar(1, 2, 3)
barfoo 1, 2, 3

Cheers,
Daniel

[email protected] wrote:

if u.nil?
nil
else
other code
end

But the “return nil if u.nil?” thing both terminates the method and
provides a visual cue that u being nil is a terminal condition. So
it’s partly style, but once you decide to do a mid-method return, you
have to use “return”.

In this case a completely different solution is possible:

def authenticate(login, pass)
u = find(:first, :conditions => [“login = ? AND verified = 1 AND
deleted
= 0”, login]) and
find(:first, :conditions => [“login = ? AND salted_password = ? AND
verified = 1”,
login, AuthenticatedUser.salted_password(u.salt,
AuthenticatedUser.hashed(pass))])
end

:slight_smile:

robert

On Jan 9, 2006, at 8:57 AM, [email protected] wrote:

 return self.security_token

Programmer’s individual style. You could replace that line with:

security_token

Seems like every time I check, code with a ‘return’ runs slower
than code without. Less typing and faster. I say drop the return.

Jim

Dirk M. wrote:

#rest of processing

end

this looks a lot nicer than placing your entire method in if/else
code. greetings, Dirk.

In this case you wouldn’t use return values to flag this error. It’s is
a
typical case for exceptions.

def mett(arg)
raise ArgumentError, “#{arg.inspect} is not a String” unless String

arg

further processing

end

And taking this even further, in the light of Duck Typing ™ usually
no
type checks of this kind are made at all. :slight_smile:

Kind regards

robert

On 1/10/06, Jim F. [email protected] wrote:

Seems like every time I check, code with a ‘return’ runs slower
than code without. Less typing and faster. I say drop the return.

Confirmed:

require ‘quickbench’

class Test
def initialize(test)
@test = test
end

def test
@test
end

def get_test
return @test
end
end

t = Test.new(“something”)
QuickBench.go(3000000, 25) {}

END
t.test
t.get_test

Results:


| QuickBench Session Started |

3000000 Iterations
                              user     system      total        real
  1. t.test 2.860000 0.000000 2.860000 (
    2.859000)
  2. t.get_test 3.078000 0.000000 3.078000 (
    3.094000)

Fastest was <1. t.test>

Ryan

Ryan L. wrote:

require ‘quickbench’
def get_test

Fastest was <1. t.test>

Ryan

Most weird. Let’s hope someone notices and the compiler is modified to
plain drop tail-returns. That is, if “return” is a reserved word and
thus not viable to being overridden by someone who codes with a dead
chicken in his left hand :stuck_out_tongue_winking_eye: (Gotta love it when flexibility bites you
back. daydreams about clean blocks)

Robert K. wrote:

if arg.class==String
In this case you wouldn’t use return values to flag this error. It’s is a

Kind regards

robert

Indeed, arg.to_str would be a more consistent duck typecheck. (Le Groan,
what gruesome terminoogy sees the light of day.)

David V.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs