But, then again, the compiler could enforce rejecting access to the instance
variables (direct state) of the "owner" of the home context. Still, I see
what Alan means. Similar to being bitten by modifying a literal string...

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Randal L. Schwartz
> Sent: 18 September 2007 6:06 pm
> To: Alan Kay
> Cc: The general-purpose Squeak developers list
> Subject: Re: Blocks (Re: Fear and loathing of the 
> "perification" ofSmalltalk)
> 
> 
> >>>>> "Alan" == Alan Kay <alan.kay at vpri.org> writes:
> 
> Alan> Sure. I simply meant that a block containing an 
> assignment to the 
> Alan> internal state of an object can be passed around willy nilly to 
> Alan> other objects and some random time in the future can be 
> sent value 
> Alan> and presto! you've cause a side effect on the internal state of 
> Alan> the object that will be very hard to track down if it's a bug.
> 
> But that's no different from some other object holding a 
> reference to your object, then invoking a named method at a 
> random time.
> 
> Putting dangerous things into a named method is no better or 
> worse than putting dangerous things into a closure/block.  
> You are still in control about the damage that can be caused 
> "from the outside".
> 
> In fact, I'd go so far as to argue that a closure is nothing 
> more than an unnamed method, and should be treated with the 
> same care and feeding as named methods.
> 
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - 
> +1 503 777 0095 <merlyn at stonehenge.com> 
> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, 
> etc. etc. See PerlTraining.Stonehenge.com for onsite and 
> open-enrollment Perl training!
>