[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@gmail.com:
On Mon, May 28, 2012 at 3:18 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
28.05.2012, 17:08, "Alessio Stalla" alessiostalla@gmail.com:
On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
28.05.2012, 16:22, "Anton Vodonosov" avodonosov@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
The conclusion of my opinion about abcl-jfli contrib:
1. Worth to have. One of the advantages of jfli which has not been mentioned here is that it's portable: the java interacting lisp code based on jfli will work on other Lisps, not only on ABCL (jfli home page for more info about it: http://jfli.sourceforge.net/)
2. About new-class, as I see now some efforts are needed to bring it back (not sure how difficult it is). I personally am not able to be involved into the development in the foreseeable future.
If no-one can fix it now, there is no sense to delay the progress by the new-class issue: if there is a ready to use abcl-jfli version without new-class, we could create a contrib in this state, and maybe file a track ticket for new-class support.
Nothing prevents someone to add the new-class support later.
Best regards, - Anton
armedbear-devel@common-lisp.net
-
Anton Vodonosov