[armedbear-devel] Is anybody interested in jfli-abcl?

Alessio Stalla alessiostalla at gmail.com
Mon May 28 13:00:53 UTC 2012


On Mon, May 28, 2012 at 2:22 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> Hello
>
> 23.05.2012, 17:06, "Alex Mizrahi" <alex.mizrahi at gmail.com>:
>>
>> (I've found this updated version:
>> https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/jfli-abcl/jfli-abcl.lisp
>> But haven't yet checked if it works with latest ABCL and what are
>> improvements against old one.)
>
> The changes comparing to the original version are annotated in the sources.
>
> In my opinion new-class is important to have because creating classes is often
> needed when interacting with java libraries: to create a thread we need a Runnable,
> to handle a button click we need an ActionListener, to find files in directory we
> need a Filter.

Note that in many cases (Runnable, ActionListener, etc.) you're
actually implementing interfaces, not classes. That functionality is
already in ABCL (jmake-proxy) and has been since a long time, because
it is directly supported by the Java Reflection API.

Extending concrete classes *is* useful or even necessary in certain
scenarios, but you can do a surprising amount of work with just
interfaces, assuming the libraries you're dealing with are written in
good style. And runtime-class is usable right now in a lot of cases;
at the last European Lisp Symposium, I showed a proof of concept work
where I replaced Groovy with Lisp in my employer's flagship product,
to write custom action classes with the Stripes framework: to do that,
I used present-day runtime-class. The most important missing feature
is the ability to call superclass methods, and that's something I'm
working on these days; constructors are only useful generally if the
superclass mandates them, and fields are rarely necessary because
method implementations can be closures.

> If independent version of new-class is not ready, probably it's possible to
> deliver runtime-class a a contrib, and user if wants to load it should provide
> asm.jar in the classpath?
>
> I mean to have jfli-abcl contrib which provides all the functions which possible
> without runtime-class/asm.jar, but when we need new-class, we can get it
> too by having asm.jar in classpath and loading the runtime-class contrib?

That would be possible, but I object that having 2 different APIs for
the same thing is a potential source for confusion.

Peace,
Alessio

-- 
Some gratuitous spam:

http://ripple-project.org Ripple, social credit system
http://villages.cc Villages.cc, Ripple-powered community economy
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my current open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework




More information about the armedbear-devel mailing list