[Armedbear-devel] Comments on Cyrus's proposal for JSS static calls

[Cyrus Harmon]

On Aug 20, 2014, at 11:14 PM, Mark Evenson <evenson at 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 at 57027b0d {63DCBF1B}>

ABCL-CDK> (#"getBytes" "foo")
#<jarray [B at 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 at common-lisp.net
> http://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/20140821/784de6ec/attachment.html>