smalltalk - java side by side 
Author Message
 smalltalk - java side by side

I converted my posting to an HTML table which may be easier to read and
print.  I also did some minor corrections and rewordings.  The newer
version is at:
    http://www.*-*-*.com/

Thank you Doug for putting up the previous version at your site.

Quote:


>> ...
>> Note that I also have a Java preprocessor that converts:
>>     [String a, String b | return a + b;]
>> into the highly noisy
>>     new Function2Arg() {
>>         public Object valueWith_with(Object a, Object b) {
>>             return (String) a + (String) b
>>     }};
>> so there is hope for Java having something close to (and actually
>> in many ways better than) blocks.

> This sounds interesting.  Is the pre-processor publicly availiable?
> In what ways are they better than Smalltalk blocks?

Well, the preprocessor is mine and I plan to make it freely available
along with the interfaces that it uses (e.g. Function2Arg).  It is
currently loosely connected in with a larger preprocessor that is for a
more specific purpose, so I have to re-extract it.  The preprocessor was
built using JavaCC ( http://www.*-*-*.com/ ) which is a way-cool
LL(k) grammar generator.  I still would rather have the equivalent of
the Smalltalk metadata and compiler available, but in time I will.  So
it will be freely available but I don't know the time schedule for
extraction and cleaning.

"In what ways are Java's Anonymous Classes better than Smalltalk's
Blocks?"
I think Java's approach is better in a a number of ways and I will try
to explain them briefly here.  Please don't let this encourage a
language war: I am neither a Smalltalk or Java bigot and I have enough
years under my belt with each [OK, only two-digit months with Java] to
understand and appreciate their good and bad features.  Also, it was
hard to respond to this concisely because I wanted to make this readable
to someone who didn't know Smalltalk that well [i.e. sorry for the extra
verbage Mike].

Just to make sure everyone knows what I am referring to, Java 1.1 allows
you to have "Inner" and "Anonymous" classes.  Inner means a class that
is defined in the context of another class or a method.  Anonymous
simply means a class that does not need to be named because it is only
instanciated in a single context (Declaration and instance-creation are
done in the same, single spot).  See
http://www.*-*-*.com/
for full documentation, but at the bottom of this posting is an extract
from the introduction to inner classes.

I believe Java's Anonymous Inner Classes are: conceptually cleaner, less
complex, less special, more manageable, and more powerful than
Smalltalk's blocks.  I believe Smalltalk's blocks are easier to express
and are within a more powerful and elegant language: so effectively
Smalltalk's blocks are more powerful because of their context where
Java's inner classes have more potential but are restrained by their
environment.  Some of these differences are because the general concept
of "easy-to-express-and-instanciate-classes" is cleaner than what is
occuring for blocks.  Other differences are because Smalltalk is very
clean which causes Blocks to become somewhat messy, and Java has mess
that allows inner classes to be clean.

** Conceptually cleaner **
Smalltalk is a very clean and consistent language, but part of that
comes from dumping things into Blocks.  For example, Smalltalk maintains
the Object paradigm for control structures: we send messages to Booleans
to control the flow within a method.  For example:
    amHappy ifTrue: [...doHappyThings...] ifFalse:
[...doUnhappyThings...].
In this context the inline-blocks are simply objects that respond to
#value.  The behavior is just as if we had done the following:
    amHappy ifTrue: (DoHappyThingsClass new) ifFalse:
(DoUnhappyThingsClass new).
Where both classes respond to #value.  This is one of the more
impressive conceptual cleanliness within Smalltalk.  
    But what about "^" (return)?  Well, a return ends the current method
and returns the value following the return.  But not for blocks, the
return not only ends the statements within the block (and would normally
return the #value of the block), the return ends the method the block
was "declared-and-instanciated" in.  For example the following
    >>exampleMethod
        value := (amHappy ifTrue: [...doHappyThings...^5] ifFalse:
[...^6]).
        ^value + 3
does not do what it "should".  The method will either return 5 or 6,
(not 8 or 9) because Blocks have a special-power to return from multiple
contexts.  The reasons are obvious enough: Smalltalk has to have some
way to have loop structures and it would be nice to be able to exit a
method earlier than the last line.  Unfortunately this makes blocks
messy.

For Java there is absolutely no difference in behavior between a method
declared in an inner context and one declared in the outer-most
context.  Returns always do the same thing: return from the current
method context.  This is cleaner.  On the other hand, Java has a whole
slew of control structures and non-object primitive types (e.g. boolean)
that allow for control flow.  Also, there is some fancy scoping going on
for Java inner methods, but that is also true for Blocks.

** Less Complex **
Blocks (full-blown blocks) rely on the fancier ability to have
Contexts-as-objects.  They are one of the few non-Meta features in
Smalltalk that require the ability to treat method contexts as real
objects.  Java's inner classes don't need to have method contexts
because they are always copy-value based: that is why my original
posting note [21] mentioned that method variables have to be "final":
unchanging so the block (and programmer) can be sure the inner class is
allowed to copy in the value of the variable.  

** Less Special **
Blocks are also very special.  You can't (OK, it is "difficult" to)
define you own classes that have: the characteristics of a block's
access to a method state, the ability to return from the calling context
instead of the execution context, or the ability to be "literally"
defined in another context.  In Java the inner class concept is a
mechanism for your own classes.

** More manageable **
Smalltalk has dynamic typing, but blocks take this a bit too far.  Any
block could take either 0,1,2,3, or n arguments (and no other amount),
and after sending the #value... message you have no idea what the block
will return.  The problem is that there is not even a way to support
good conventions (a boolean test beginning with #is...) for either the
block creator or the block caller.  You just have to have discipline.  
   For Java an inner class supports whatever methods the class supports,
so you can have methods named:
        execute     for no return value
        value       for a return value
        isTrue      for a boolean return value
and support both the declarer and the caller in doing what they meant to
do.  (Note that this is independent of static typing).  Inner classes
support developers better and document the program behavior better.

** More Powerful **
Java's inner classes are more powerful because they are full-blown user
defined classes and full-blown objects.  They can have multiple methods,
keep independent state (without relying on the method's context), have
multiple objects change their state, allow domain-specific inquiries
into their status, and whatever else you would do with a normal
user-defined object.

***** Smalltalk ******
I would go into what is better about Smalltalk's blocks, but I am (and
you probably are) tired by now.  A quick summary is that Smalltalk's
whole class environment (especially booleans, collections, and adapters)
make blocks very powerful, and block are very easy (sometimes too easy)
to use in most situations.  Java has a very modest "Kernel" class
library, so inner class and Functors have no intrinsic use.  You have to
build everything from scratch.  Also the inner class notation is very
cumbersome (something like 20+ characters to do what 5 do), which is why
I originally did the preprocessor and support environment.

Overall, I believe Java has the upper hand for this one design concept.
I have found Functors (simple command-like objects that are usually
instanciated just like blocks) to be very expressive in my own
development projects, and tend to use them more than I would Smalltalk
block because of that expressiveness (OK, the static typing and no
#perform makes them more important too).  But it will be a while before
the class libraries are around to make Java inner classes anywhere near
as generally powerfull as Smalltalk blocks.

--Mark

http://www.*-*-*.com/

See
http://www.*-*-*.com/
-----
What are top-level classes and inner classes?

In previous releases, Java supported only top-level classes, which must
be members of packages. In the 1.1 release, the Java 1.1 programmer can
now define inner classes as members of other classes, locally within a
block of statements, or (anonymously) within an expression.

Here are some of the properties that make inner classes useful:

     The inner class's name is not usable outside its scope, except
perhaps in a qualified name. This helps in structuring the classes
within a package.
     The code of an inner class can use simple names from enclosing
scopes, including both class and instance members of enclosing classes,
and local variables of enclosing blocks.

Inner classes result from the combination of block structure with
class-based programming, which was pioneered by the programming language
Beta. Using block structure with inner classes makes it easier for the
Java programmer to connect objects together, since classes can be
defined closer to the objects they need to manipulate, and can directly
use the names they need. With the removal of restrictions on ...

read more »



Fri, 08 Oct 1999 03:00:00 GMT  
 smalltalk - java side by side

Quote:

>Any block can be thought of as the definition of a singlton class whose
>instance reponds to #value (or #value: or whatever depending upon the
>number of arguments).  When thought of in this manner Smalltalk seems
>perhaps even a bit more conceptually clean.  It also suggests that
>block syntax could be extended to allow specification of additional
>methods other than #value. If you do this, you quickly arrive at a
>constuct that is very similar to Java's inner classes. As you point
>out, such a construct would be very useful for creating adaptors of
>various sorts.  BTW, I believe this general indea was first proposed
>for Smalltalk by L. Peter Deutsch in the late 80's.  I'm not aware of
>anyone who has actually imnplemented it.

In a way, Self implements exactly this--a block is just a (unique)
object with a value (or value: etc.) method.  Some magic is required
to explain the lexical access, but otherwise it's just like a regular
object.  If you don't need lexical access, you could just write (|
value = ( ...some code...) |) which is a (unique) object literal
containing just a value method.

BETA also allows anonymous "inner" classes (in fact, they inspired the
more spartan Java variant).

-Urs

--
----------------------------------------------------------------------------

Computer Science Dept.,  University of California,  Santa Barbara,  CA 93106
(805) 893-3960           fax: (805) 893-8553



Fri, 08 Oct 1999 03:00:00 GMT  
 smalltalk - java side by side

Mark,

I thought you presented an excellant comparision of blocks and inner
classes. However, I thought one of your most important points was
somewhat burried:



Quote:
>    amHappy ifTrue: [...doHappyThings...] ifFalse:
>[...doUnhappyThings...].
>In this context the inline-blocks are simply objects that respond to
>#value.  The behavior is just as if we had done the following:
>    amHappy ifTrue: (DoHappyThingsClass new) ifFalse:
>(DoUnhappyThingsClass new).
>Where both classes respond to #value.  This is one of the more
>impressive conceptual cleanliness within Smalltalk.

Any block can be thought of as the definition of a singlton class whose
instance reponds to #value (or #value: or whatever depending upon the
number of arguments).  When thought of in this manner Smalltalk seems
perhaps even a bit more conceptually clean.  It also suggests that
block syntax could be extended to allow specification of additional
methods other than #value. If you do this, you quickly arrive at a
constuct that is very similar to Java's inner classes. As you point
out, such a construct would be very useful for creating adaptors of
various sorts.  BTW, I believe this general indea was first proposed
for Smalltalk by L. Peter Deutsch in the late 80's.  I'm not aware of
anyone who has actually imnplemented it.

Quote:
> ** Less Complex **
> Blocks (full-blown blocks) rely on the fancier ability to have
> Contexts-as-objects.  They are one of the few non-Meta features in
> Smalltalk that require the ability to treat method contexts as real
> objects.  Java's inner classes don't need to have method contexts
> because they are always copy-value based: that is why my original
> posting note [21] mentioned that method variables have to be "final":
> unchanging so the block (and programmer) can be sure the inner class is
> allowed to copy in the value of the variable.  

I don't see why you believe that full block semantics requires the
objectification of method contexts. There are ways to implement full
block semantics that do not do this (see, for example, VSE 3.1). As
another way to think about it, blocks are Scheme/Lisp closures plus a
catch/throw mechanism. This combination of features have been widely
implemented in ways that do not explicitly reify the execution stack.

Allen Wirfs-Brock
Instantiations, Inc.



Sat, 09 Oct 1999 03:00:00 GMT  
 smalltalk - java side by side

Quote:



> > ** Less Complex **
> > Blocks (full-blown blocks) rely on the fancier ability to have
> > Contexts-as-objects.  They are one of the few non-Meta features in
> > Smalltalk that require the ability to treat method contexts as real
> > objects.  Java's inner classes don't need to have method contexts
> > because they are always copy-value based: that is why my original
> > posting note [21] mentioned that method variables have to be "final":
> > unchanging so the block (and programmer) can be sure the inner class is
> > allowed to copy in the value of the variable.

> I don't see why you believe that full block semantics requires the
> objectification of method contexts. There are ways to implement full
> block semantics that do not do this (see, for example, VSE 3.1). As
> another way to think about it, blocks are Scheme/Lisp closures plus a
> catch/throw mechanism. This combination of features have been widely
> implemented in ways that do not explicitly reify the execution stack.

Actually, I don't believe it, I just accidentally wrote it.  I was at
the
time thinking about "VisualWorks" but wrote "Smalltalk".  I guess I
believe
that you have to do something complex to allow a block to continue to
refer to method local variables that are not "final"/constant, but I
will
have to check into this a bit more to see if I am missing something
obvious.
Barring that I can only think of certain dialect specific features (e.g.
the
very sneaky thisContext pseudo-variable in VW) that would require
reifying
the execution stack.  

With multiple dialects of Smalltalk it is hard to keep track of exactly
what
I was comparing to Java, but I tried to be as general as possible and
ST-80ish when not.  Block functionality is one of those areas that has
historically been quite different in the various Smalltalks.  Thank you
for the correction.

I will retract the assertion and replace it with a comment: I believe
the
choice of having "final" variable values and copy semantics is probably
worth the trade-off between slightly less functionality and potentially
much less complexity for both Smalltalk blocks and Java inner classes.

--Mark



Sat, 09 Oct 1999 03:00:00 GMT  
 smalltalk - java side by side



Quote:
> I guess I
> believe
> that you have to do something complex to allow a block to continue to
> refer to method local variables that are not "final"/constant, but I
> will
> have to check into this a bit more to see if I am missing something
> obvious.

The "obvious" thing to do is to allocate any such variables (writable
temps referenced from inner blocks) in the heap instead of on the
stack.After all, these are the only temporary variables that do not
have a LIFO lifecycle. Think in terms of a heap allocated variable
"context" that is created at the same time as the activation record.
All normal variables/arguments still get allocated on the stack. In
actual usage, very few methods actually have writable variables that
are referenced from non-inlined blocks so there is minimal performace
overhead to this technique.

Allen Wirfs-Brock



Sat, 09 Oct 1999 03:00:00 GMT  
 smalltalk - java side by side


Quote:
>"In what ways are Java's Anonymous Classes better than Smalltalk's
>Blocks?"
>** Conceptually cleaner **
>Smalltalk is a very clean and consistent language, but part of that
>comes from dumping things into Blocks.  For example, Smalltalk maintains
>the Object paradigm for control structures: we send messages to Booleans
>to control the flow within a method.  For example:
>    amHappy ifTrue: [...doHappyThings...] ifFalse:
>[...doUnhappyThings...].
>In this context the inline-blocks are simply objects that respond to
>#value.  The behavior is just as if we had done the following:
>    amHappy ifTrue: (DoHappyThingsClass new) ifFalse:
>(DoUnhappyThingsClass new).
>Where both classes respond to #value.  This is one of the more
>impressive conceptual cleanliness within Smalltalk.  
>    But what about "^" (return)?  Well, a return ends the current method
>and returns the value following the return.  But not for blocks, the
>return not only ends the statements within the block (and would normally
>return the #value of the block), the return ends the method the block
>was "declared-and-instanciated" in.  For example the following
>    >>exampleMethod
>        value := (amHappy ifTrue: [...doHappyThings...^5] ifFalse:
>[...^6]).
>        ^value + 3
>does not do what it "should".  The method will either return 5 or 6,
>(not 8 or 9) because Blocks have a special-power to return from multiple
>contexts.  The reasons are obvious enough: Smalltalk has to have some
>way to have loop structures and it would be nice to be able to exit a
>method earlier than the last line.  Unfortunately this makes blocks
>messy.

I personally would like to see a different definition of
smalltalk blocks and returns.

I think if we had one definition that is used for control
structures and a completely different definition that is
used for deferred execution we would be much better off.
If the "deferred execution block" had a different syntax
then there would also be less confusion where the two
different blocks could be used.  Furthermore, if a return
were executed in a deferred execution block then only
a local block return would occur, so we would not have
the problem of a second return from the defining method
context.

I would also like to see the addition of a local block
return added to the blocks used for control structures.
I realize that this may not be easy but it would be nice
to have (as I see it, there would be some confusion as to
which block the local return is returning from, the conditional
block or the block containing the conditional).

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
19 Tilley Ave.                  VW and ENVY/Developer
Newport, RI  02840

http://www.craftedsmalltalk.com
===========================================================



Sat, 09 Oct 1999 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. smalltalk - java side by side

2. Lines Side by Side?

3. Class side vs Instance Side??

4. Printing group footers side-by-side

5. Report details side by side

6. New MVS REXX Utility: Compare partitioned datasets side-by-side - pdsmatch.zip (1/1)

7. client side or server side scripting- new web user

8. Two text widgets side by side?

9. Java script server side

10. Server-Side Active Content - Smalltalk in HTML?

11. Is it possible to concatenate two text files side by side?

12. How to put columns of two files into one file (side by side)?

 

 
Powered by phpBB® Forum Software