<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Aug 20, 2014, at 11:14 PM, Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Erik asked me to comment on [Cyrus’s proposed patch][1] to extend JSS’s<br>SHARPSIGN-DOUBLE-QUOTE use in static method calls to accept a string as well as<br>a symbol to designate the object.<br></blockquote><div><br></div>Thanks for taking a look.</div><div><br><blockquote type="cite"><br>Unfortunately, changing JSS in the manner means that one can no longer use<br>SHARPSIGN-DOUBE-QUOTE on object descended from java.lang.String, for the<br>reasons described in the [JSS README][2]:<br><br>[…]<br>Static calls are possible as well with the #" macro, but the<br>first argument MUST BE A SYMBOL to distinguish <br><br> (#"getProperties" "java.lang.System")<br><br>from <br><br> (#"getProperties" 'java.lang.System) <br><br>The first attempts to call a method on the java.lang.String object<br>with the contents "java.lang.System", which results in an error, while<br>the second invokes the static java.lang.System.getProperties() method. <br>[…]<br></blockquote><div><br></div>It wasn’t (isn’t) at all clear to me that in the first example we’re trying to call a method on a java.lang.String object. In fact I thought lisp strings and java strings were distinct classes (not exactly in the CLOS or java sense) of objects:</div><div><b><br></b></div><div><div><b>ABCL-CDK> "foo"</b></div><div><b>"foo"</b></div><div><b><br></b></div><div><b>ABCL-CDK> (java:jnew "java.lang.String" "foo")</b></div><div><b>#<java.lang.String foo {64E135F}></b></div><div><br></div><div>I would have thought that calling a method on a string would have failed. But, of course, I am wrong:</div><div><br></div><div><div><b>ABCL-CDK> (#"getBytes" (java:jnew "java.lang.String" "foo"))</b></div><div><b>#<jarray [B@57027b0d {63DCBF1B}></b></div><div><b><br></b></div><div><b>ABCL-CDK> (#"getBytes" "foo")</b></div><div><b>#<jarray [B@3d0c15a {7E45FDAA}></b></div></div><div><br></div></div><div>So, somewhere along the line “foo” is being treated as a java.lang.String. Hmm… Now I see your objection to my patch.</div><div><br></div><div><blockquote type="cite">Other than perhaps for aesthetic reasons, is there some functionality that<br>using strings enables here? To argue about preserving character case in<br>strings as opposed to the case folding implicit in symbols doesn’t seem to be<br>applicable, because JSS currently ignores case when searching for matching JVM<br>symbols. In 2006, when I first understood the ignoring case bit of JSS, I was<br>a bit worried that there would be cases where this resulted in ambiguity and<br>errors, but in the ensuing years I have yet to run into a single problem with<br>this design decision.<br></blockquote><div><br></div>I don’t like using naked strings as class identifiers as they’re too long to type and too error prone. So I use variables that evaluate to strings:</div><div><br></div><div><br></div><div><div><b>(defmacro jimport (java-package class &optional package)</b></div><div><b> `(eval-when (:compile-toplevel :load-toplevel :execute)</b></div><div><b> (defparameter ,(apply #'intern class</b></div><div><b> (when package (list package)))</b></div><div><b> (concatenate 'string (symbol-name (quote ,java-package))</b></div><div><b> "."</b></div><div><b> (symbol-name (quote ,class))))))</b></div><div><b><br></b></div><div><b>(jimport |java.util| |Vector|)</b></div><div><br></div><div>This lets me do:</div><div><br></div><div><b>(java:jnew |Vector|)</b></div><div><br></div><div>and, with my patch,</div><div><br></div><div><div><b>ABCL-CDK> (jimport |java.lang| |System|)</b></div><div><b>|System|</b></div><div><b>ABCL-CDK> (#"getProperties" |System|)</b></div></div><div>… which fails on a stock ABCL.</div></div><div><br></div><div>A minor convenience, I’ll admit.</div><div><br><blockquote type="cite">Therefore, I am not currently persuaded that introducing an asymmetry to<br>SHARPSIGN-DOUBLE-QUOTE (“It works on any java Object except those which descend<br>from java.lang.String; for those instances you have to use the JFI”) to use<br>strings as well as symbols to specify static methods is worth it. But please<br>argue back if you disagree…<br></blockquote><div><br></div>I was trying to make it work on any object that isn’t a lisp string, not realizing that lisp and java strings are more closely related than I thought.</div><div><br></div><div>thanks for the feedback,</div><div><br></div><div>Cyrus</div><div><br><blockquote type="cite"><br>[1]: <a href="https://github.com/slyrus/abcl/commit/9ec0fb26c7b7e9470349b1c4bd9be6fa4b053177">https://github.com/slyrus/abcl/commit/9ec0fb26c7b7e9470349b1c4bd9be6fa4b053177</a><br>[2]: <a href="http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown#L55">http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown#L55</a><br><br>-- <br>"A screaming comes across the sky. It has happened before but there is nothing <br>to compare to it now."<br><br><br><br><br><br><br>_______________________________________________<br>Armedbear-devel mailing list<br><a href="mailto:Armedbear-devel@common-lisp.net">Armedbear-devel@common-lisp.net</a><br>http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel<br></blockquote></div><br></body></html>