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

[Anton Vodonosov]

[forwarding Alessio's reply to the list - was my mistake to send the previous letter
to him directly, instead of Reply All]
-----------------------------------------------------------------------------------------------------

28.05.2012, 17:25, "Alessio Stalla" <alessiostalla at gmail.com>:

On Mon, May 28, 2012 at 3:18 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:

>  28.05.2012, 17:08, "Alessio Stalla" <alessiostalla at gmail.com>:
>>  On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
>>>   28.05.2012, 16:22, "Anton Vodonosov" <avodonosov at yandex.ru>:
>>>>   If independent version of new-class is not ready, probably it's possible to
>>>>   deliver runtime-class a a contrib [...]
>>>   I've checked the ABCL sources and see that runtime-class.lisp is now
>>>   included into ABCL. So we don't even need to create a contrib for it.
>>>
>>>   Could anyone help me understand the problem with new-class, why removing
>>>   it? Namely, when the asm.jar will be needed,
>>>
>>>   What I understand now:
>>>
>>>   1. abcl-jfli function jrc calls java:jnew-runtime-class.
>>>   2. java:jnew-runtime-class needs asm.jar.
>>  2. is wrong. jnew-runtime-class used to require asm, was disabled, and
>>  was reintroduced (incomplete) without a dependency to asm and with a
>>  slightly different API. In other words, jrc right now is probably
>>  broken.
>>
>>  To restore jrc right now, you'd need to restore runtime-class.lisp
>>  from version control, and bundle it in contrib under a different
>>  package (assuming it still works with present-day asm).
>  Ah I see, it's different runtime-class. Thanks for the explanation.
>>  That would be possible, but I object that having 2 different APIs for
>>  the same thing is a potential source for confusion.
>  Yes, but it's also the way of software evolution: we use some API,
>  notice it's deficiencies, deprecate it and introduce new, better
>  API. Let me note that it could have been called runtime-class2
>  to avoid confusion and compatibility issues.

Yes, maybe it could, but the situation as I saw it was that
runtime-class was effectively dead code nobody was using (and in fact,
until now nobody asked about it on this list).

>  Probably now, if packaging the old runtime-class as a contrib, we will
>  need to rename it to old-runtime-class, or even deprecated-runtime-class.

Or just deprecated:runtime-class, or backwards-compatibility:..., so
you can shadowing-import-from it and forget about it.

>  Could you explain about the asm.jar dependency in case of the
>  deprecated-runtime-class? Would it be a load-time dependency,
>  or a call-time dependency?

IIRC, it is a call-time dependency, but note that I never used the old
runtime-class, so I may be wrong.

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