[armedbear-devel] Using ABCL with large Java app

[Vsevolod Dyomkin]

Btw, I thought of a slightly modified version, that uses counts of
arguments verbatim in the definition:

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

(defmethod method ((object clos-mirror-object) (argcount (eql 2)) &rest
&key arg1 arg2 &allow-other-keys)
   ...)

And you can also leave the count out if there's just one method (at
the inconvenience of providing nil as a second argument).

Regarding implementing custom dispatch: I imagine how this can be done with
define-method-combination, but I don't see how you'll be able to use
defgeneric/defmethod then. (With a wrapper macro maybe?)


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

> Thanks for the feedback.   I'm not sure about that approach because most
> methods don't share the same name.  I'd have to know in advanced which do,
> which don't, an what the special keys are.  This doesn't amount to anything
> more than name mangling generics.  I am still stuck having to know too many
> special cases.  Having, essentially, custom dispatching code in the
> generics based on argument count and types seems to be the only clean
> solution I can think of.  The problem  of course, is that it is a bit
> difficult to implement - auto generation of this based on Java reflection.
>  I'd love to find an easier solution to implement that doesn't make it hard
> to use.
>
> Thanks for the idea!!
>
> Blake
>
>
>
> On Fri, Feb 15, 2013 at 9:40 PM, Vsevolod Dyomkin <vseloved at gmail.com>wrote:
>
>> 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/cc7102d5/attachment.html>