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.
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. […]
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.
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…
[1]: https://github.com/slyrus/abcl/commit/9ec0fb26c7b7e9470349b1c4bd9be6fa4b0531... [2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown#L55
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
-- "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
On Thu, Aug 21, 2014 at 3:17 PM, Cyrus Harmon ch-lisp@bobobeach.com wrote:
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)How about
(#2"getProperties" "java.lang.System")
We could make that work. (or any number other than 0 or 1 - I thought 8 might be nice since if you squint through a vertical bandpass it would look like two pairs of quotes stacked ;).
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
-- "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
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Cyrus Harmon -
Mark Evenson