[squeak-dev] Re: Block closure and scope problem

Bert Freudenberg bert at freudenbergs.de
Sat May 28 10:07:55 UTC 2011


On 28.05.2011, at 07:11, Rodney Polkinghorne wrote:

> Levente Uzonyi, replying to me:
>> self means the defining method's receiver
> 
> In other words, [ self ] refers to the same thing as self.  That makes sense.
> 
>> Here ^ means return from the defining method.
> 
> That's what I was missing: answering a message differs from returning
> from a block.  Thank you.
> 
> Bert Freudenberg:
>> your approach is very unusual for Smalltalk. Smells lispy to me.
> 
> I expected someone might say that.
> 
>> Blocks are typically used to make a single class customizable
> 
> I want DotMorph's instances to derive their position from a complex
> number, elements 5 and 7 of a particular array, or whatever.  This is
> my reaction to StarMorph storing 20 vertices as 40 numbers, only 6 of
> which are independent: the center, orientation, number of points, and
> radii.  I'd prefer a PolygonMorph that derived each vertex from the
> same data, but in different ways.  Dots seemed like a good place to
> start.
> 
> It's possible - likely - that I've missed the intent of Morphic's
> design, and there's a good reason for StarMorph to do that.

Speed. Think of the vertex array as a cache.

>  I'm
> learning Morphic by trial and error, and would be very happy to find a
> better way.
> 
> Why have a subclass at all?  To provide an instance variable in case
> there's nowhere better to store the locus.  (So the locus is stored
> literally, instead of being derived from an abstract representation.)

If that is all you want, each morph can have a dictionary of arbitrary properties. See #valueOfProperty: / #setProperty:toValue:.

- Bert -





More information about the Squeak-dev mailing list