[armedbear-devel] Using ABCL with large Java app

[Blake McBride]

Your solution solves a subset of the problem but doesn't work generally.  I
must be able to dispatch based on argument number and each argument type
while supporting numerous combinations with only slight variations.

Thanks!

Blake

On Fri, Feb 15, 2013 at 10:17 PM, Vsevolod Dyomkin <vseloved at gmail.com>wrote:

> 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/a05240f1/attachment.html>