Re: Namespaces and ObjC

Subject: Re: Namespaces and ObjC

From: "Timothy J. Wood" <email@hidden>

Date: Tue, 23 Aug 2005 08:15:59 -0700

Delivered-to: email@hidden

On Aug 23, 2005, at 7:14 AM, ObjM2 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 ...

ObjM2_FooLib__FooClass *fooclass = [[ObjM2_FooLib__FooClass alloc] init];

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.

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:

@interface NSNamespace : NSObject

{

...

}

+ (NSNamespace *)globalNamespace;

+ (NSNamespace *)namespaceNamed:(NSString *)name; // takes 'foo::bar' format strings

- (NSNamespace *)parentNamespace;

- (NSArray *)childNamespaces

- (NSNamespace *)createChildNamespace:(NSString *)name;

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

// open question of whether you can have other symbols in the namespace (global variables like NSString notification names would be particularly useful)

@end

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):

NSNamespace *foundation = [NSNamespace namespaceNamed:@"com::apple::foundation"];

[[NSNamespace globalNamespace] addClass:[foundation classNamed:@"Array"] withName:@"NSArray"];

- possibly allow for compatibility with ObjC++. It's a shame that ObjC @try exceptions don't use the C++ EH framework...

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.

-tim

_______________________________________________ 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 This email sent to email@hidden

Follow-Ups:

Re: Namespaces and ObjC
- From: Marco Scheurer <email@hidden>
Re: Namespaces and ObjC
- From: ObjM2 <email@hidden>

References:

>Namespaces and ObjC (From: ObjM2 <email@hidden>)

>Re: Namespaces and ObjC (From: glenn andreas <email@hidden>)

>Re: Namespaces and ObjC (From: ObjM2 <email@hidden>)