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

On 14 Apr 2005, at 22:20, Mark Hubbart wrote:

> On 4/14/05, David A. Black <[e-mail]> wrote:
>
>> I still don't like the look-ahead aspect of this.
>
> I don't see it as a "what happens after" type thing; more of a "what's
> my position" type thing. It would simply glance into the parse tree,
> checking if this method call is in the outer ring, so to speak, of a
> statement. If it is, the function can optimize itself not to bother
> returning any expensive values, since they would just be GC fodder.

Sneaking a peak up the parse tree is quite difficult, because its 
linked down, not up.  Besides, if you have expensive operations your 
API should allow users to avoid them until necessary by not bundling 
them with other operations.

>> It is no step at all in kind, and only a small step in degree, from
>> the question "Is what I return going to be used in a chain?" to the
>> question "Is what I return going to be chained to the 'flatten'
>> method?" (or any other specific method).  It strikes me as a whole
>> type of knowledge that is not the business of the method that's
>> currently executing.
>
> 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.

If you want to avoid doing work in the future depending on some 
condition, make it explicit!

Build your API to be flexible enough that developers do the work when 
it needs to be done.

> Since we haven't been given an example of how just knowing whether the
> return value is used is harmful, I'll present a simpler example of its
> possible usefulness. I'll even shorten the method name a bit :)
>
> class MarkovChain
>   [...]
>   def parse_text(text)
>     words = text.scan(WORDS)
>     links = link_words(words)
>     add_to_library(links)
>     links.compute_statistics if return_value?

This looks poorly factored and too highly coupled to me.  Instead you 
should have a method that updates the links/library (#add_text), and a 
separate method that computes statistics (#current_stats).  If 
computing statistics is not a critical part of parsing text, then it 
should not be in the text parsing method!

Decoupling makes much more sense because I can stream hundreds of 
megabytes through #add_text (more than can fit in memory) and when I'm 
done streaming I can grab #current_stats.

To do that with your return_value? proposal I would have to stream all 
the values through #parse_text then call #parse_text with an empty 
string to get the statistics I want out.  This makes for very ugly code 
(magic value of '').  (And if you wish to respond by saying "oh, I 
could break that up anyhow" then what is the point of using 
return_value? if your API no longer needs it?)

> The more I think on this, the more it seems like a good feature. Sure
> it's a little magic, but then, so is callcc :) And if it wasn't a
> little magic, we would just be implementing it ourselves, in pure
> Ruby.

callcc is not very magical, in fact, it is quite simple to implement.  
It only appears magical because you don't use it.

You can't easily, or even with a little work, or a lot of magic, 
implement a return_value? feature because you cannot reliably, or 
without great expense, obtain the information required to implement it.

Either you need to save extra state (which will be unused 99% of the 
time), or you need to figure out where you are in the parse tree by 
moving to the top of the method and re-tracing your steps (which may 
not work, because you may take a different path), or you need to add 
bidirectional links to the parse tree.  Any of these changes come with 
a severe performance penalty.

The better solution is to implement a properly factored API.

-- 
Eric Hodel - [e-mail] - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04