[Openmcl-devel] packages and Objective-C
R. Matthew Emerson
rme at thoughtstuff.com
Mon Oct 29 10:42:22 PDT 2007
When programming in Objective-C, Apple recommends that programmers use
a prefix when naming classes (and other things). See the link below.
<http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingBasics.html#//apple_ref/doc/uid/20001281-1002226-BBCJECED
>
Objective-C has no packages or namespaces, so this prefixing technique
is a way to help avoid symbol collisions. In Common Lisp, though, we
have the package system.
The question then, is can we/should we do anything about mapping the
package system onto Objective-C classes in the bridge?
As a proof-of-concept, I made modifications to the current bridge to
prefix a form of the package name onto Objective-C class names.
The basic idea is to find the symbol's home package, convert dashes in
the (shortest) package name to underbars, and stick that onto the
front of the class name with two underbars.
So, this sort of thing:
(in-package "CCL")
(defclass lisp-preferences-panel (ns:ns-panel)
()
(:metaclass ns:+ns-object))
(objc:defmethod #/sharedPanel ((self +lisp-preferences-panel))
....)
(objc:defmethod (#/show :void) ((self lisp-preferences-panel))
...)
Gets mapped into this:
+[CCL__LispPreferencesPanel sharedPanel]
-[CCL__LispPreferencesPanel show]
As another example. suppose you've got a package "COOL-STUFF". You
define cool-stuff::my-
great-class in that package, and it gets turned into
"COOL_STUFF__MyGreatClass".
(Of course, it might be possible to come up with some other, perhaps
better, sort of name mangling scheme, but I just picked this one
because it was easy.)
It's necessary to stick to valid C identifiers for class names because
Interface Builder won't let you enter any other characters.
Now, there's little hope that this sort of ad hoc scheme will cover
every possible contingency. For example, it won't work with packages
named "ORG.FOO.SOMETHING", or "ODD_BALL".
But, I think this, or something like this, could be made to work in
the usual case.
More information about the Openmcl-devel
mailing list