Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!torn!nott!cunews!freenet.carleton.ca!FreeNet.Carleton.CA!av578
From: av578@FreeNet.Carleton.CA (Wayne Beaton)
Subject: Re: Interesting Block Behavior
Message-ID: <Cx8EEo.vo@freenet.carleton.ca>
Sender: news@freenet.carleton.ca (Usenet News Admin)
Organization: The National Capital FreeNet, Ottawa, Ontario, Canada
Date: Thu, 6 Oct 1994 03:16:00 GMT
Lines: 39


I've been sitting quitely by on the sidelines for too long.  
 
In Smalltalk, a return in a block is just like a return in a 
method.  The answer is returned to the sender of the method 
containing the definition of the block.
 
>case 2: Dictionary>>at:ifAbsent:. When the block fires, and contains an
>explicit return, where should it return to?
 
>case 3: False>>ifFalse: or True:>>ifTrue:. If the semantics were different
>than they are, where would execution go if the block contained an explicit
>return?      
 
A return in the block that you provide for an at:ifAbsent:, or an 
ifTrue:ifFalse, returns to the sender of the method which 
defines the block.
       
>case 1: ProcessScheduler>>fork:. When the block finishes, from what context
>should it return? If the block contains an explicit return, where should 
>it return to?         
 
When a process is spawned using the fork message, returns 
don't make sense.  Forked process don't return (where would 
they go).  If the block computes something interesting, you 
have to set up another method of communication.
                  
If you get confused about blocks, here's a simple rule:  You 
can only return from a block that you pass forward (as a 
message arguement), not one you pass backward (as the result 
of a method).  
 
Actually, I find blocks much easier to understand when I don't 
think about them at all.  Try it, you'll like it.
 
Wayne
The Object People        
wayne@objectPeople.on.ca
(don't let the freenet address kid you).     
