On Aug 24, 2005, at 12:15 AM, Timothy J. Wood wrote:
Now, if you want to use a class written in ObjM2 from within ObjC
code, then you'd have to know the prefixing scheme and refer to
the class in its raw prefixed name, like ...
that's not really going to fly with ObjC developers is it?
Given the dynamic runtime around ObjC, this name mangling
approach seems like a very minimal solution that would be pretty
fragile.
For the avoidance of doubt, we are not talking about name mangling
here, but giving classes a prefix just like Apple's prefix is NS (for
historical reasons, objviously).
The only difference is that the prefix isn't fixed (like NS, or OM or
M2) but it is taken from the library's name in which the class was
defined.
Now, in ObjC there is no equivalent for library modules, so you may
think of the library name as the name of the source file in which you
have multiple classes.
But other than that, the prefix is just a prefix like NS and CF. So
there is no mangling of names and consequently the scheme would not
be fragile, unless somebody else is using the same prefix and that
code is supposed to go into the same project. But the danger of that
is much greater with the current convention of using two letter
prefixes. Longer prefixes will actually reduce the chance of a
collision.
The difficulty I described has to do with the fact that the ObjC
compiler does not know the difference between a very long class name
and a class with a long prefix. In fact it doesn't even know anything
about two letter prefixed either. As a result of this, we have to
refer to the classes with their full name, including the prefix.
We have to do ...
NSString *string = [[NSString alloc] init];
instead of ...
String *string = [[String alloc] init];
while the compiler would magically insert that NS prefix for us.
Now, this is manageable and no big deal as long as the prefixes are
short. However, if the prefix is longer, like when using the name of
the library module in which the class is declared, then it becomes
inconvenient to type that long class name every time we want to use
the class.
Thus the way to shorten the typing is to define a macro
#define ClassName TooLongToTypeClassName
And in fact this is what Apple's documentation actually recommends.
The name mangling technique used by other languages which use bridges
to interface with Cocoa, like for example PyObjC, is not required for
ObjM2 because we decided to adopt the ObjC object model and the
bracketed Smalltalk message syntax, lock, stock and barrel.
Thus, in ObjM2 a method selector is identical to an ObjC method
selector, colons are allowed as part of the method name and infix
parameters are handled. Basically everything is the same as in ObjC,
just the base language is Modula-2 instead of C and the data
encapsulation facilities such as modules, import and export lists
offer an opportunity to introduce namespaces although this is
constrained by the ObjC runtime and the desire to allow mixing of
ObjM2 and ObjC in the same project.
In my (possibly deluded) dreams I see ObjC namespaces being first
class citizens, just like Class and Protocol. I have no idea how
this would like in Modula-2, but in ObjC I would imagine:
- (void)addClass:(Class)cls; // just like objc_addClass, but scoped
- (void)addClass:(Class)cls withName:(NSString *)name; // new;
creates an alias of the class
- (void)poseClass:(Class)cls; // just like class_poseAs, but scoped
- (Class)classNamed:(NSString *)className; // just like
NSClassFromString(), .... you get the point
very nice !!!
You shall be promoted to chief namespace architect :-)
The question is though if this would be possible to do without making
amendments to the ObjC runtime for which you will need Apple's buy-
in, which is probably too much to expect.
As for Modula-2, it has a pretty decent namespace mechanism: each
module has its own namespace and modules can be nested ad infinitum.
Yet, that doesn't really help us because the constraints of the ObjC
runtime won't allow us to take full advantage of the way M2 does
namespaces. So the idea is to come up with something workable that
allows mixing of ObjM2 and ObjC code in the same project. With a bit
of luck and patience, Apple may eventually implement namespaces with
proper runtime support and then we can just hook into that. Until
then, we try to come up with something that is at least "good enough".
The global NSClassFromString() would remain, but would take a
"foo::bar" path. This would:
- allow for backwards compability since Foundation would have
something to the effect of the following (possibly compiler
generated rather than actual written code):
At any rate, getting back to my original point... this shouldn't
be done via name mangling since that is static. Instead, you'd add
a new section in the Mach-O file like ".objc_namespaces" that would
have a flattened list of namespace instances (much like static
NSStrings work). The ObjC runtime would look for this when loading
runtime information due to a Mach-O module load occurring and would
register the original state of the namespaces with the runtime.
This glosses over the really hard questions (how do namespaces
and categories interact, for example), but hopefully conveys the
idea that namespaces can be viewed as just a refactoring of the
existing ObjC runtime.
Interesting thoughts.
Would you be interested in taking this further? If so, let's talk off-
list.
thanks for the feedback
regards
ObjM2 project
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/objc-language/email@hidden
