Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > return_on

Reply
Thread Tools

return_on

 
 
Trans
Guest
Posts: n/a
 
      01-10-2007
Sometimes i do this:

return x if x

Anyway to code it as:

return_on x

t.


 
Reply With Quote
 
 
 
 
Pit Capitain
Guest
Posts: n/a
 
      01-10-2007
Trans schrieb:
> Sometimes i do this:
>
> return x if x
>
> Anyway to code it as:
>
> return_on x


It's not very nice, but you could wrap the whole method body in a block
and use throw/catch behind the scenes.

Regards,
Pit

 
Reply With Quote
 
 
 
 
Simon Strandgaard
Guest
Posts: n/a
 
      01-10-2007
On 1/10/07, Trans <(E-Mail Removed)> wrote:
> Sometimes i do this:
>
> return x if x
>
> Anyway to code it as:
>
> return_on x
>


I cannot recall I ever have used return, in this way,
but my coding style may be 5% different than yours.
Maybe I can improve my minimal insight.

Any good (larger) examples of this thing?


--
Simon Strandgaard
http://opcoders.com/

 
Reply With Quote
 
Srinivas JONNALAGADDA
Guest
Posts: n/a
 
      01-11-2007
On 10-Jan-2007, at 20:09, Trans wrote:
> Sometimes i do this:
>
> return x if x
>
> Anyway to code it as:
>
> return_on x
>
> t.


I do this quite often, as well! We need a macro system

JS

 
Reply With Quote
 
Devin Mullins
Guest
Posts: n/a
 
      01-11-2007
Trans wrote:
> Sometimes i do this:
> return x if x
> Anyway to code it as:
> return_on x


I'm wondering if continuations (or continuations + set_trace_func to
catch the method end) could be used to achieve that, but am not a whiz
at callcc, and am up past my bedtime (hence am not going to experiment
w/ it).

Is there a Weirich in the house?

Devin
(Even if it can be implemented using such hackery, I might consider that
a smell that it's so different, and doesn't map to Ruby's ways, and be
hesitant to use such a beast in GP code.)

 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      01-13-2007

Simon Strandgaard wrote:
> On 1/10/07, Trans <(E-Mail Removed)> wrote:
> > Sometimes i do this:
> >
> > return x if x
> >
> > Anyway to code it as:
> >
> > return_on x
> >

>
> I cannot recall I ever have used return, in this way,
> but my coding style may be 5% different than yours.
> Maybe I can improve my minimal insight.
>
> Any good (larger) examples of this thing?


I don't really have any examples that are repleat with it, but as to
insight it's especially convenient when caching a return value:

def x
return_on @cache[]
# do stuff
@cache[] = result_of_stuff
end

this gets rid of an extraneous variable too b/c otherwise, the more
efficient impl. is:

def x
r = @cache[]
return r if r
# do stuff
@cache[] = result_of_stuff
end

funny thing i just came across a similar case for break. how would you
DRY this up and get rid of 'result'?

result = nil
files.each do
result = require file
break if result
end
if result
...

t.


 
Reply With Quote
 
Devin Mullins
Guest
Posts: n/a
 
      01-13-2007
Trans wrote:
> funny thing i just came across a similar case for break. how would you
> DRY this up and get rid of 'result'?
>
> result = nil
> files.each do
> result = require file
> break if result
> end
> if result
> ...


Well, this is much easier:

if files.any? {|file| require file }
...

C'mon, Trans.

Devin
(Or am I missing something obvious?)

 
Reply With Quote
 
Pit Capitain
Guest
Posts: n/a
 
      01-13-2007
Trans schrieb:
> I don't really have any examples that are repleat with it, but as to
> insight it's especially convenient when caching a return value:
>
> def x
> return_on @cache[]
> # do stuff
> @cache[] = result_of_stuff
> end
>
> this gets rid of an extraneous variable too b/c otherwise, the more
> efficient impl. is:
>
> def x
> r = @cache[]
> return r if r
> # do stuff
> @cache[] = result_of_stuff
> end


You could also implement this as

def x
@cache[] ||= (
# do stuff
result_of_stuff
)
end

> funny thing i just came across a similar case for break. how would you
> DRY this up and get rid of 'result'?
>
> result = nil
> files.each do
> result = require file
> break if result
> end
> if result
> ...


If "result" is only a flag whose value you don't need later, you could do

if files.find { |file| require file }
...
end

Regards,
Pit

 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      01-13-2007

Devin Mullins wrote:
> Trans wrote:
> > funny thing i just came across a similar case for break. how would you
> > DRY this up and get rid of 'result'?
> >
> > result = nil
> > files.each do
> > result = require file
> > break if result
> > end
> > if result
> > ...

>
> Well, this is much easier:
>
> if files.any? {|file| require file }
> ...


Cool, I forget that #any? will break after the first true encounter. I
used #find as pit suggested (which can return any value actually). But,
that wasn't really my point. Such a solution breaks the analogy to the
original return case --whihc can't be DRYed-up that way.

T.


 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      01-13-2007

Pit Capitain wrote:
> Trans schrieb:
> > I don't really have any examples that are repleat with it, but as to
> > insight it's especially convenient when caching a return value:
> >
> > def x
> > return_on @cache[]
> > # do stuff
> > @cache[] = result_of_stuff
> > end
> >
> > this gets rid of an extraneous variable too b/c otherwise, the more
> > efficient impl. is:
> >
> > def x
> > r = @cache[]
> > return r if r
> > # do stuff
> > @cache[] = result_of_stuff
> > end

>
> You could also implement this as
>
> def x
> @cache[] ||= (
> # do stuff
> result_of_stuff
> )
> end


That pretty good. I rarely use ( ) as local encapsulator and probably
should consider it more often. I'm generally partial to less indention
when I can get it though.

Thanks,
T.


 
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