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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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@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@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!