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