[armedbear-devel] Using ABCL with large Java app

[Vsevolod Dyomkin]

Hello Blake,

What would you say of the following scheme for variable-argument methods:

(defgeneric method (object spec &rest &key))

(defmethod method ((object clos-mirror-object) (spec (eql :variantion1))
&rest &key arg1 arg2 &allow-other-keys)
   ...)

I.e. introducing an additional argument that you can use for dispatching of
the same-named methods belonging to one class?

Best

Vsevolod Dyomkin
+38-096-111-41-56
skype, twitter: vseloved


On Sat, Feb 16, 2013 at 1:54 AM, Blake McBride <blake at arahant.com> wrote:

> Greetings,
>
> I have a large Java app with more than 15K Java classes.  I linked it up
> with ABCL and successfully used it in several places.  However, I had a
> couple of problems that caused me to use ABCL significantly less than I had
> hoped.  I thought I would share my problems and perhaps there might be a
> helpful suggestion.
>
> Although I don't interface with most of the 15K Java classes, there are
> still a lot of classes to interface ABCL with.  I wrote some lisp code
> that, through Java reflection, creates CLOS classes that mirror the Java
> classes I wish to interface with.  In CLOS it encapsulates the Java
> instance, mirrors the class hierarchy, and creates generics to match the
> Java methods.  I found a way to create variable argument generics that feed
> fixed argument methods in order to handle the fact that similarly named
> methods can take different arguments across different Java classes.
>
> I ran into two problems that have caused me to use ABCL much less than I'd
> like to.  The first seems like won't be too hard to solve, but the second
> is something I still need to find a solution to.  Remember, I cannot build
> this interface manually.  There are too many classes and methods.
>
> The first problem is that I have Java classes and instances mirrored as
> CLOS classes and instances.  At times it was more convenient (from lisp) to
> deal with Java objects directly instead of CLOS mirrors.  While it was
> more convenient, it ended up being too confusing.  With all these classes,
> objects, and methods, it was too easy to forget what the heck I was dealing
> with at any point in the code.  I think the only answer to this is to only
> deal with lisp objects when in lisp.  This would avoid the confusion at the
> cost of wrapping and unwrapping certain Java objects at times - not too
> bad.  I would need to have a way to pack Jeve arguments from Jave when
> calling Lisp.  Doing it in Lisp is a problem because I am back to the
> confusion of knowing when I am dealing with a Java object and when a lisp
> object.
>
> The second problem has to do with the fact that a single Java class can
> use the same method name multiple times with different arguments.
>  Remember, I am using variable argument generics to handle similar Java
> method names taking different argument across different classes.  I still
> have argument checking because I dispatch to a fixed argument CLOS method.
>  However, I cannot do this within a single class.  The first obvious answer
> is to name mangle the generics.  This is too sloppy.  The other answer
> would be to name mangle the methods and have the generic be smart enough to
> dispatch to the correct method based on the argument number and types (all
> in CLOS).  This would be a lot of work so I thought I might solicit
> alternative suggestions.  Perhaps there is a simple answer that I hasn't
> come to me.
>
> Thanks.
>
> Blake McBride
>
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130216/2feb72a3/attachment.html>