dead things don't move.

From: Alan Knight
Date: Tue Aug 26, 2003 11:00:24 AM America/Denver
Resent-Cc: recipient list not shown: ;
Subject: Re: Are interfaces and inner classes workarounds for not having dynamic types?

Well, I'd consider inner classes more of a workaround for not having blocks. But interface types are definitely something that static typing imposes on you. I'm appending one of my favourite bits of discussion on this topic. It's from the Squeak list some time ago, Alan Lovejoy commenting on some discussions about Java vs. Smalltalk collections, iterations, etc. It's much funnier if you know Java well enough to understand the issues he's raising. Alan is the main body of the thing, responding in a thread that already has one response.
------------------------------------------------------------------------------------------------------------

> > > Actually, you only really have to say:
> > >
> > > aCollection.do(new BlockLike() {
> > > int value(int each) {
> > > return each.doSomething();
> > > }
> > > });
> > >
> >
> > Maybe I'm missing something, but why is
> > aCollection do: [:each | each doSomething]
> > better?
> >
>
> It's one line instead of four, which means blocks are much more
> convenient to use in Smalltakl. They are also much simpler in
> Smalltalk, because you don't have to put all the surrounding
> static type
> information.
>
> In this way, Smalltalk encourages people to play with blocks,
> while Java
> pushes in the other direction.
>
>
> Otherwise, they mostly do give you the same value, as far as I know.

Yes, but it's even worse than that.

Firstly, the class (or perhaps interface) BlockLike has to be predefined
by the programmer, it is not part of the standard language. That has
two serious consequences:

1) Programmer A (project A, department A, division A, company A,
etc) may define BlockLike, as com.companyA.core.BlockLike, but
com.companyA.core.BlockLike will NOT be known to programmer B, and
even if programmer B happens to have defined a class (or interface)
that is exactly like the one defined by programmer A, it won't be
in the same package, and so won't be statically type-compatible
with the one defined by programmer A. Therefore, the collections
(for example) defined by programmer A will not be usable with
programmer B's blocks, and vice versa. In the real world, of
course, you will define this as "BlockLike," I'll use "Functor1,"
and someone else will use "IntValuedBlock." [Remember that
Java's static typing depends upon name equivalence--based on the
fully qualified name, which includes the name of the package]
If Java had a type algebra, so that a type could be constructed
by formula (e.g., {t(x, y) = i | i extends x, y}, that is, t is
any interface that extends both x and y, where x any y are supplied
by the programmer,) then this problem could be solved by defining
BlockLike algebraicly as any interface that implements one or more
value messages (with specific argument signatures). But Java has
no type algebra, and so there is no solution to this problem.

2) When BlockLike is predefined, the programmer must decide then
and there several crucial questions: a) how many arguments does
the value message take? b) what are the types of those arguments,
if any? c) what is the return type of the value message? The
number of possible combinations (of number of arguments, argument
types, and message return types) may as well be treated as infinite,
which is clearly not practical. One possible strategy for limiting
the complexity is to a) use a different class or interface for
each different number of arguments that the value message will have
(so BlockLike0, BlockLike1, BlockLike2, etc); b) handle only the
primitive types, and Object (so ignoring short forms as semantically
unnecessary, long, double, char, boolean and Object would be the only
supported argument types); and c) only support Object as a return
type (which is forced on us by the fact that Java will not permit
messages to differ solely by return type). However, even with this
simplifying strategy, the number of different value messages with
three arguments is clearly unmanageable, and so BlockLike3 would
be practically useless unless even more simplifications were used.
So perhaps one may as well just support Object, and only Object,
as an argument type (and as a return type, for the reason mentioned
above). There are pros and cons to whichever strategy one follows
here, which pretty much guarantees that there will be many different,
and hence incompatible, implementations of BlockLike (by whatever
name).

Secondly, the example as given:

aCollection.do(new BlockLike() {
int value(int each) {
return each.doSomething();
}
});

is not syntactically correct. The identifier "do" cannot be a message name,
because it is a reserved word. One cannot send any messages to a value statically
typed as int. Collections in Java do not store ints, or any other primitive types,
in any case. So a more realistic example would be:

aCollection.valuesDo(new Functor1() {
public Object value(Object each) {
return ((SomeType)each).doSomething();
}
});

From experience with this in a shop most of whose members are not familiar
with closures in general, or with Smalltalk in particular, I can attest that
this syntax is **very** opaque to the reader, and that most will go to great
lengths to avoid having to write it. But let's continue.

In addition to "do: block1" (valuesDo(Functor1)), there are other useful messages
with a block as argument that a collection can respond to. For example, there's
"detect: block1" (detect(Functor1)). Let's compare the Smalltalk and Java
implementations:

Smalltalk:
Collection>detect: block1
self do: [:each | (block1 value: each) ifTrue: [^each]].
^self raiseValueNotFoundError

Java:
Collection::Object detect(final Functor1 block1) {
valuesDo(new Functor1() {
public Object value(Object each) {
Boolean accepted = block1.value(each);
if (accepted.booleanValue()) return each; // <<<===== this is the problem
return null;
}
});
raiseValueNotFoundError();
}

Can you see why the implementation above won't work? The problem is with the
semantics of "return," which returns you from the innermost method, instead of
from the outer method as the Smalltalk return ("^") does. There are ways around
this, of course, but they are ugly.

I could go on. Java's inner classes are not full closures, so it is difficult to
increment induction variables in the body of an inner class method. Primitive
types are not Objects, and so one cannot have blocks that operate on both objects
and primitive types (try sorting a collection using a block as the sorting rule).
Try implementing inject:into: sometime, and then find a compelling use for it
given that it can't operate on number primitives.

Java is a joke, only it's not funny.

--Alan