Interfaces and dynamic binding [was: election details *PLEASE READ*]
Klaus D. Witzel
klaus.witzel at cobss.com
Fri Feb 23 18:19:56 UTC 2007
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
More information about the Squeak-dev
mailing list
|