Hi JJ,
on Fri, 23 Feb 2007 16:51:04 +0100, you wrote:
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@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