>>>>> "Alan" == Alan Kay <[hidden email]> 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 other Alan> objects and some random time in the future can be sent value and presto! Alan> you've cause a side effect on the internal state of the object that will Alan> 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 <[hidden email]> <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! |
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: [hidden email] > [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]> > <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! > |
In reply to this post by Randal L. Schwartz
I thought this was a mailing list for developers.
Please take this to a mailing list where it is appropriate. On 15 Sep 2007, at 15 September/08:37, Randal L. Schwartz wrote: >>>>>> "Peter" == Peter William Lount <[hidden email]> writes: > > Peter> People have the right to defend their person and this right > even allows > Peter> them to make private communications public! > > Not in violation of federal law. I don't care how you feel. You > don't get to > violate the law no matter how you "feel". > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 > 777 0095 > <[hidden email]> <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! |
In reply to this post by Marcel Weiher
On 9/16/07, Marcel Weiher <[hidden email]> wrote:
> > On the other hand, having blocks is vastly superior to not having any > useful higher order mechanism, and blocks are extremely powerful. > Possibly too powerful, one of those "better old things" (lambda/ > anonymous functions) that is so useful and powerful that it stops us > looking for the actual "new" thing. For me personally, what makes Smalltalk so powerful is that it's OO beautifully mixed with functional programming. If you take away blocks you take this away. I would like to see some other solution that would preserve the perceived lost encapsulation while having the same power. |
Free forum by Nabble | Edit this page |