On Feb 12, 2006, at 20:16, Alex Combas wrote:

> On 2/11/06, Matthew Smillie <M.B.Smillie / sms.ed.ac.uk> wrote:
>
>>> The block should take two parameters and return a boolean value.
>
> Its the thing with the boolean that I dont get. This seems to be  
> asuming
> some prior knowledge of a particular ruby method.
> I've searched Array and String and dont see anything that fits.

Well, it's meant to illustrate a very handy property of blocks, but  
it doesn't assume anything about knowledge of a particular Ruby  
method.  It does seem to assume some previous knowledge of how  
searching and sorting works, though.

> What is this boolean supposed to show? Booleans can me on/off
> true/false, found/not_found, or many other things.

Booleans don't mean anything by themselves, the semantics is imposed  
by how they're used.  Let's say I give you two methods that operate  
on two strings: is_shorter? and is_longer?  The boolean value 'true'  
has two precisely opposite meanings.

So in this case, the semantics of the boolean value is dependent only  
on what happens in the block.  The method calling the block (i.e.  
find_it) will treat 'true' in the same way no matter what its  
particular semantics are.

For example, "true" could mean "the first argument is shorter than  
the second" or vice-versa.  It could mean that the first argument has  
more vowels than the second.  It could mean that the first argument  
starts with a letter closer to 'a' than the second argument.  Passing  
any of these blocks to find_it will change exactly what's being  
found.  (This is a big hint.)

> If the guide just stated what the boolean is for, or even better what
> method they want used that returns a boolean I'm sure this would
> be a rather simple problem.

Well, from the above examples, I hope it's clear that they don't have  
any particular method in mind that returns a boolean.  Just that  
there's a block which takes two things, and returns a boolean value.   
find_it will deal with a 'true' result from one block in exactly the  
same way as it deals with a 'true' result from any other block, and  
what that means only depends on the block.

David gave you a few big hints, so I'll go one baby step further to  
start you off: reduce the problem to a simpler one.  Assume that  
you're trying to implement longest_string by doing only pair-wise  
comparisons.  The comparison is done by a separate method which takes  
two strings and returns true/false.  You'll need to decide the  
following questions, among others:
  - What does a 'true' result from the comparison method mean?
  - HOw should you order the comparisons to get the desired overall  
result?

I would expect that when you get that far, you'll be able to make the  
connection with how the block version is supposed to work, and why  
it's able to do any number of different jobs depending on what block  
you give it.  If not, I'll be happy to answer any other questions you  
have (though off-list, probably, since this seems to be getting less  
and less general-interest).

> Finding the longest or shortest string in an array is so trivial.
> This really seems more like an exercise on howto structure blocks
> and pass variables to methods.
>
> result = arr.sort_by {|w| w.length};
> shortest,longest = result[0],result[-1]

You're exactly right.  The point isn't to teach you how to find the  
shortest or longest string in an array.  It's more to teach you how  
Ruby can use blocks, how the results of general methods can be  
altered depending on the block they're passed, and how you might go  
about writing such a general method.

Programming examples generally tend towards trivial, easily solved  
things with baroque restrictions on how to do them.  Trivial examples  
are picked precisely *because* they're trivial - the student knows  
what needs to be done, and can easily see when you have the right  
answer and when you don't.  The restrictions are used to illustrate  
particular techniques and ways of thinking about problems in general.

best of luck,

matthew smillie.



----
Matthew Smillie            <M.B.Smillie / sms.ed.ac.uk>
Institute for Communicating and Collaborative Systems
University of Edinburgh