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

[Mark Evenson]

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/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