Hi JJ,

on Fri, 23 Feb 2007 16:51:04 +0100, you wrote:
>> From: Andreas Raab <andreas.raab at gmx.de>
>> Reply-To: The general-purpose Squeak developers  
>> list<squeak-dev at lists.squeakfoundation.org>
>> To: The general-purpose Squeak developers  
>> list<squeak-dev at lists.squeakfoundation.org>
>> Subject: Re: election details *PLEASE READ*
>> Date: Thu, 22 Feb 2007 22:05:50 -0800
>>
>> J J wrote:
>>> Namespaces ok, but the way they have been done is not always that  
>>> great.  Modules are pretty much the same thing, and interfaces?  No.   
>>> Traits are much better then interfaces imo.
>>
>> Modules is one area where IMO Java shines. Not necessarily because of  
>> the language part but because of the whole ClassLoader/JAR/Applet  
>> pipeline (just run Dan's SqueakOnJava in the browser and then think  
>> about what must be true to be able to handle that in a reasonably  
>> secure fashion). It's the best deployment solution I am aware of.
>
> Ah, I wasn't thinking about them from that angle.  Good point.
>
>> In the namespace area I think Python wins hands-down, because they  
>> manage to tie namespaces (and modules) into the object model so nicely.  
>> Traits better than Interfaces? Well that remains to be seen.
>
> Interfaces in Java are mostly just a pain IMO.  They provide a few extra  
> protections here and there, and give the programmer hints as he browses  
> the code, but since you can't add a default implementation to them they  
> just enforce a certain level of code duplication.  At least in my  
> experience and most of the Java programmers I know (admittedly not the  
> whole world).

You can use Java's interfaces for modeling the dynamic binding[1] of  
Smalltalk ;-) At runtime, no change is needed in the JVM. But the existing  
gcj's require you to cast message sends. To get rid of the cost of the  
casts I run a small utility which patches the bytecodes in the .class  
files with noops. May sound crazy at first sight but, it works and I know  
of no bytecode verifier which complains (so much for the static checking  
== safe software mythodology ;-)

Here's how:

- create an empty interface, name it smalltalk
- make a distinct new interface for each method
- the latter extends the former

Then when you want to expose an implementor, just use " implements " as  
before, for example "implements smalltalk.doIt, smalltalk.printIt".

You can extend all the existing public non-final library classes with the  
above. The JVM will only throw an exception if an implementor is actually  
missing (like DNU does). And your instance variables and args and temps  
will be of the singular type smalltalk.

When time permits (rare) I work on a compiler which reads Smalltalk source  
code and emits JVM bytecode (already compiles itself). But blocks and  
exceptions will be a pain :(

> So from a usefulness point of view I think Traits already should be  
> better, and once the tools support them they will give the same hints  
> the Java implementation does at least.

IMO Java's interfaces and Traits do not compare. To give a nogo example:  
with traits you can mix required methods and provided methods. Translated  
this means that your library classes would be abstract (and as a  
consequence cannot be instantiated within their own library). So people  
use newInstance() and then cast (sometimes preceded by Class.forName and  
other expensive reflections), all the way down the bloat.

/Klaus

P.S. from the doc of newInstance() "Use of this method effectively  
bypasses the compile-time exception checking that would otherwise be  
performed by the compiler". Not compile-time safe, that is.

-----------
[1] http://www.ibm.com/developerworks/java/library/j-cb11076.html