Re: return_value? [Was: Re: want_object? - possible?]

On 4/15/05, David A. Black <[e-mail]> wrote:
> On Sat, 16 Apr 2005, Mark Hubbart wrote:
> 
> > On 4/15/05, Eric Hodel <[e-mail]> wrote:
> >> On 14 Apr 2005, at 22:20, Mark Hubbart wrote:
> >>>
> >>> The example above, while being very funny, is nothing like what's
> >>> being suggested:
> >>>  - it's a custom method grabbing absurdly specific external context
> >>> information
> >>>  - it's using the requested information to do something entirely silly
> >>> in it own right
> >>> By using this example, it appears that you are trying to say that it's
> >>> a slippery slope; from a method telling you whether a return value is
> >>> in a position to be used, to a specialized method call which tells you
> >>> whether a specific method of a certain class will be called on the
> >>> result.
> >>
> >> I think the (snipped) example was highly illustrative.
> >
> > Maybe I'm wrong. The code seemed intended to be ridiculous, a parody
> > of "what might happen". I mean really, "subsequently_flattened?"? But
> > I suppose I might have misjudged.
> 
> It's more an example of what would have happened, already, with a
> #return_value_used? method -- namely, there would be leakage of
> knowledge about the next method call into this method call, which I
> think is bad.  Having a facility that tells you whether you are being
> succeeded by a call to #flatten is just a minor variant of having a
> facility that tells you whether you are being succeeded by another
> method call at all.  I used that example, not to warn of unreasonable
> uses that might lie beyond a reasonable use, but to bring into sharper
> relief the problems that inhere in the whole thing in any form.

Okay, I misunderstood then. Still, I don't think they are in the same
category. I see a big difference between the question "should I bother
returning a value?" (or more precisely, "will there be any references
to my returned value after this method call?") and "what will be in
the future for my returned value?". Using it for anything other than
deciding whether to return a value would be looked down on. It should
be *only* for optimization purposes, not to change states.

The way I perceived it, the method would not be about whether there
will be a subsequent method call. It's about whether the value will be
stored or used. So return_value? inside the method do_something would
be true in these cases:

  do_something.do_something_else
  puts do_something
  f = do_something

but not in this case:

  do_something # return value is ignored.

This code:

def foo
  if return_value?
    STDERR.puts "returning value"
    23
  else
    STDERR.puts "not returning a value"
  end
end

foo
num = foo
puts num
puts foo

would print:

not returning a value
returning a value
23
returning a value
23

There are other features in Ruby that could be horribly abused, but
they usually aren't, in production code anyway. Also, as far as this
method goes, I don't see much potential for using it as a dirty hack
for anything.

I just realized that this could conceivably be useful in things like
drb, where you might end up sending a huge marshalled object across
the network as a return value. If it's not going to be used, why
return it over the network, simply to be discarded?

As for the lookahead aspect of it, you could alternatively look at
this this as more of an immediate lazy evaluation; instead of
computation of values being delayed in case it's not needed, it would
be computed immediately, but only if it was needed.

cheers,
Mark