This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cond-expand feature testing for presence of a Java class


On Apr 4, 2011, at 2:29 AM, Per Bothner wrote:

There is Translator#namespaceResolve(Object). That seems to work - see
the attached patch. But note teh patch uses "class-exists:" as the prefix,
not "class". I was confused about the "class:" prefix. It's been used in
Kawa as a URI scheme in a namespace URI. However, it is not supported as a
prefix in a compound symbol.


So there is no compatibility or even pseudo-compatibility reason for using
the syntax (cond-expand (class:com.example.AClass ...))
Thus I think a slightly more verbose "prefix" would be better:
(cond-expand (class-exists:com.example.AClass ...))

Works here, too. So, "class:" is special; are there other namespace- or
compound-symbol-prefixes that aren't supported and can fail in non- obvious
ways? It would be handy for them to be listed in the namespace section of
the manual.


Another idea is to use a question-mark as the delimiter:
 (cond-expand (class-exists?com.example.AClass ...))

I'm leaning towards the class-exists:CLASS_NAME syntax,
but welcome suggestions or opinions.

I don't really like the look of a question mark there; it would be too easy to forget that "class-exists?" isn't a function or macro to be applied, as in (class-exists? CLASS_NAME).

I have no objection to class-exists:CLASS_NAME as the syntax. It's a
little on the long side, but it does make the intended meaning of the
corresponding cond-expand feature requirement fairly self-evident.

Jamie

--
Jamison Hope
The PTR Group
www.theptrgroup.com




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]