On Sep 14, 2007, at 3:51 PM, Alan Kay wrote:
Re: unification of blocks and methods (procedures).
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc.
But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...)
On Sep 16, 2007, at 2:52 AM, Marcel Weiher responded:
A block is just an unattached/anonymous method body and a method just a block with a name that's attached to a class. However, with that unified view it becomes immediately obvious that there is something wrong with blocks. After all, we don't directly call methods in other cases, that's early binding and a Bad Thing. Instead we send messages to objects. How does not naming the method body make this type of early binding and leaking implementation better?
That's not quite true. In Smalltalk, blocks *are* objects, and it's not possible to directly "call" a block. Instead, you send the message #value to it. This isn't early binding, because there are other things that respond to #value - MessageSends, for example, or Seaside's Continuations. Heck, Object provides a trivial implementation too.
I see what Alan was getting at about violating encapsulation: if you create a block that can access an object's internal state, then use it as a method of some *other* object, you end up with two objects that are quite intertwined, a sort of quantum entanglement between objects. I've done some neat stuff with that in Javascript, but I do agree that it dilutes the strict purity of object orientation that one finds in Smalltalk.
This is a bit strange, but I'm coming around to the idea that one of Smalltalk's greatest strengths is actually its block syntax. It'd be pretty tough to find a lighter-weight syntax for a closure. Even Lisp requires you to type out L-A-M-B-D-A, although the pain can be mitigated with macros. Ruby comes close, but {} doesn't actually create a real object. Javascript would be soooo much better if you didn't have to type out "function(){}" to create a closure. The lightness of Smalltalk blocks is what makes gems like #ifTrue:ifFalse: not only possible but practical.
Alan, can you elaborate on what you mean by "super time bombs?"
Colin