> I solved another RosettaCode task with ErsatzLisp, which doesn't need
> any call to 'javac':
> (interesting also the other solutions, in plain text and
I like the plain text version:-D
I have implemented this example using my wl interpreter and added it
into the git repository under the name swing9.l so that you can compare.
>> - Much better was writing a function handler (see swt3.l example) which
>> basically does curry, e.g.
> Yes, that's also how I did it in one test, e.g. using the Frame object
> to hide it. I directly used the Lisp 'curry' function:
> (java Button "addActionListener"
> (interface "java.awt.event.ActionListener"
> (curry (Button Frame) (Ev)
> (java Frame "hide")
Your 'interface' function has two restrictions:
1) It can create proxy instance only for one interface while in Java,
one can create proxy instance for many interfaces.
2) It is not possible to create one handler for many events and be aware
of which event was invoked.
>> We also discussed on IRC, how to define the 'paint' method on JPanel. I
>> haven't looked whether it's possible to use an "interface" proxy somehow
>> without the need for compiling some stub class for "class" proxy (as
>> opposed to java "interface" proxy). If not, that's a limitation of
>> Swing. In SWT, it is possible; see swt2.l example:
>> (S 'addPaintListener (jproxy NIL 'onPaint PaintListener))
> I see. But this is because you are using PaintListener from Eclipse,
> which is not available in a normal runtime environment.
Yes, that's a limitation of Swing. If Swing was better designed, it
would not be an issue.
> The limitation of not being able to define a "class" proxy is more one
> of the JVM Proxy than just of Swing, it seems.
> Proxy.newProxyInstance() doesn't accept a normal class, just an
Yes, shame. I briefly looked at how Clojure implements proxy (it
supports both interface and class proxy) and it seems it just compiles a
new class for it instead of going through the dynamic proxy option.