Blocks (Re: Fear and loathing of the "perification" ofSmalltalk)
gazzaguru2 at btinternet.com
Tue Sep 18 17:27:22 UTC 2007
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>
> Perl/Unix/security consulting, Technical writing, Comedy,
> etc. etc. See PerlTraining.Stonehenge.com for onsite and
> open-enrollment Perl training!
More information about the Squeak-dev