<div dir="ltr">Hello Blake,<div><br></div><div>What would you say of the following scheme for variable-argument methods:</div><div><br></div><div style>(defgeneric method (object spec &rest &key))</div><div style><br>

</div><div style>(defmethod method ((object clos-mirror-object) (spec (eql :variantion1)) &rest &key arg1 arg2 &allow-other-keys)</div><div style>   ...) </div><div style><br></div><div style>I.e. introducing an additional argument that you can use for dispatching of the same-named methods belonging to one class?</div>

<div style><br></div><div style>Best</div><div class="gmail_extra"><br clear="all"><div>Vsevolod Dyomkin<div>+38-096-111-41-56</div><div>skype, twitter: vseloved</div></div>
<br><br><div class="gmail_quote">On Sat, Feb 16, 2013 at 1:54 AM, Blake McBride <span dir="ltr"><<a href="mailto:blake@arahant.com" target="_blank">blake@arahant.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Greetings,<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>Thanks.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Blake McBride</div><div><br></div>
</font></span><br>_______________________________________________<br>
armedbear-devel mailing list<br>
<a href="mailto:armedbear-devel@common-lisp.net">armedbear-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
<br></blockquote></div><br></div></div>