Re: Anonymous class - I don't know how to...

On Jun 29, 9:30 am, Andreas Leitgeb <a...@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Twisted <twisted...@xxxxxxxxx> wrote:
You can work around it too, by using final arrays or final objects
with mutable fields. In fact, you can get closure-like behavior:

It's good that you mentioned the use of arrays for sharing
non-final data with a closure. I plainly forgot to mention this
workaround, myself.

However, I didn't understand the necessity of involving exceptions.
whenever the closure has done its job, you just access the array
element in the outer object, no matter if any exceptions were
thrown from the closure or whether it returned normally.

Even more, if you pass the closure to somewhere, where it is
supposed to be "used" more than once, then your exception-throwing
closure will break that after its first use.

Surely there are cases, where you want to throw exceptions
from the closure, but that isn't at all related to sharing data.

The exception is to do the other thing closures are supposed to be
able to do -- return from the enclosing function. In Smalltalk you can
just [^value] inside a block, and the return doesn't simply exit the
block, it exits the function with the block literal inside it and
returns the value specified. To emulate this in Java you would throw a
runtime exception from a method of an anonymous inner class, and catch
it in the method that passes it to another call.

Yes, if it gets stored and used later, after the original method has
exited, the exception will bomb the JVM. So? That's a bug -- in
Smalltalk, it is likewise a bug if you store a [^value] somewhere and
eventually execute it after the original context has already returned.
Bugs like these are supposed to result in a stack trace from some
uncaught exception in Java, as with NullPointerException and the
like. :)

In practise, I don't see much use for return-from-context capability
in Java, versus its handiness in something like Smalltalk. The
interesting thing is that it is actually there, if obscure and
demanding some syntactic salt. (It's also not as robust, in that bad
code that catches and discards arbitrary RuntimeExceptions in the call
chain can break it. Then again, Smalltalk closures are non-reentrant!
Threading in Java is so much less painful. :))

.

Relevant Pages

  • Re: statische Typisierung
    ... generics entferne habe ich noch lange keine Sprache die nicht statisch typisiert ist. ... Java ist und war ein Mittelding, wobei Java's "Mitte" sehr nahe bei der statischen Typisierung anzusiedeln ist. ... Ich habe auch vor Eclipse durchaus mal ein paar 100 Zeilen Code geschrieben bevor ich es durch den COmpiler gejagt habe. ... mir ein Interface definiere und meinem Code beibringe damit umzugehen und selbst wenn ich dann annonyme innere Klassen verwende um die Closure zu implementieren leidet die Lesbarkeit und Anwendbarkeit darunter. ...
    (de.comp.lang.java)
  • Re: [OT] Ruby vs. Helma
    ... Wann hast du dir denn Groovy angesehen? ... Methode ist auch eine Closure liefert. ... > einfachere Schnittstelle in Richtung Java zu bieten und zweitens sollte ... erfolgt dann aber ohne Methodenaustausch zur Laufzeit und als statischer Methodenaufruf. ...
    (de.comp.lang.java)
  • Re: dynamic type checking - a pauline conversion?
    ... > Inner classes are the closest thing Java has to a closure. ... "What is a function object? ...
    (comp.object)
  • Re: Java 7 features
    ... be nice if it were a la Smalltalk: ... and the found closure invoked or else a default closure ... LargeInteger with faster multiplies at large sizes, ... representing an error-bounded quantity, and suchlike; ...
    (comp.lang.java.programmer)
  • Re: =?ISO-8859-1?Q?=DCberladen?= funktioniert nicht
    ... wie es ursprünglich vorgesehen war? ... Indem man die Variablen an ... ziemlich das einzige Sprach-Mittel von Smalltalk (was du doch ... wie du das ohne Closure hinbekommst. ...
    (de.comp.lang.java)