On Aug 20, 2014, at 11:14 PM, Mark Evenson <evenson@panix.com> wrote:

Erik asked me to comment on [Cyrus’s proposed patch][1] to extend JSS’s
SHARPSIGN-DOUBLE-QUOTE use in static method calls to accept a string as well as
a symbol to designate the object.

Thanks for taking a look.

Unfortunately, changing JSS in the manner means that one can no longer use
SHARPSIGN-DOUBE-QUOTE on object descended from java.lang.String, for the
reasons described in the [JSS README][2]:

[…]
Static calls are possible as well with the #" macro, but the
first argument MUST BE A SYMBOL to distinguish

    (#"getProperties" "java.lang.System")

from

    (#"getProperties" 'java.lang.System)     

The first attempts to call a method on the java.lang.String object
with the contents "java.lang.System", which results in an error, while
the second invokes the static java.lang.System.getProperties() method.     
[…]

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:

ABCL-CDK> "foo"

"foo"

ABCL-CDK> (java:jnew "java.lang.String" "foo")

#<java.lang.String foo {64E135F}>

I would have thought that calling a method on a string would have failed. But, of course, I am wrong:

ABCL-CDK> (#"getBytes" (java:jnew "java.lang.String" "foo"))

#<jarray [B@57027b0d {63DCBF1B}>

ABCL-CDK> (#"getBytes" "foo")

#<jarray [B@3d0c15a {7E45FDAA}>

So, somewhere along the line “foo” is being treated as a java.lang.String. Hmm… Now I see your objection to my patch.

Other than perhaps for aesthetic reasons, is there some functionality that
using strings enables here?  To argue about preserving character case in
strings as opposed to the case folding implicit in symbols doesn’t seem to be
applicable, because JSS currently ignores case when searching for matching JVM
symbols.  In 2006, when I first understood the ignoring case bit of JSS, I was
a bit worried that there would be cases where this resulted in ambiguity and
errors, but in the ensuing years I have yet to run into a single problem with
this design decision.

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:

(defmacro jimport (java-package class &optional package)

  `(eval-when (:compile-toplevel :load-toplevel :execute)

    (defparameter ,(apply #'intern class

                          (when package (list package)))

      (concatenate 'string (symbol-name (quote ,java-package))

                   "."

                   (symbol-name (quote ,class))))))

(jimport |java.util| |Vector|)

This lets me do:

(java:jnew |Vector|)

and, with my patch,

ABCL-CDK> (jimport |java.lang| |System|)

|System|

ABCL-CDK> (#"getProperties" |System|)

… which fails on a stock ABCL.

A minor convenience, I’ll admit.

Therefore, I am not currently persuaded that introducing an asymmetry to
SHARPSIGN-DOUBLE-QUOTE (“It works on any java Object except those which descend
from java.lang.String; for those instances you have to use the JFI”) to use
strings as well as symbols to specify static methods is worth it.  But please
argue back if you disagree…

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.

thanks for the feedback,

Cyrus

[1]: https://github.com/slyrus/abcl/commit/9ec0fb26c7b7e9470349b1c4bd9be6fa4b053177
[2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown#L55

--
"A screaming comes across the sky.  It has happened before but there is nothing
to compare to it now."






_______________________________________________
Armedbear-devel mailing list
Armedbear-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

_______________________________________________
Armedbear-devel mailing list
Armedbear-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel