Namespaces

[IngwiePhoenix]

I know, OJ strives to be like Objective-C. But something crossed my mind and I thought I'd share it:

a.oj:

@namespace App
@implementation Main
+(id)init {
    // ...
}
@end

b.oj:

@namespace Runtime
[App::Main init];

Or scoped:

@namespace Foo {
    @interface Bar
        // ...
    @end
}
@namespace Derp {
    // ...
}

function main() {
    var a = [[Foo::bar alloc] init];
}

Simply put: Namespace support in OJ? Is that possible?

[iccir]

Uhhhhhh :) Anything is possible, but there's probably a good reason why Objective-C hasn't had namespaces for 32 years ;)

In the example provided, Foo::Bar is just semantic sugar for FooBar, or Foo_Bar (if you really wanted to separate the two). This solves the collision aspect. The main power of namespaces comes from being able to use some kind of use or import directive, or otherwise being able to write shorter versions of classes. However, that both adds complexity to a compiler and makes code less verbose. Less-verbosity may be a goal of some languages, but there's a reason we write appendStringWithFormat: rather than .append() :)

[IngwiePhoenix]

Yeah, I get your point there :)

I have recently updated my code base to use namespaces, and I have some like: BIRD3\Backend\Api\Private\User\Login. One could argure about the depth of it, but to me it is rather logical.

But as you said, there is a reason ObjC does not have namespaces. So I will just have to do it another way. :)

What it "could" have been useful for is to include files into an OJ build that are not specified into the files option. I.e.:

@use Some\Deep\Namespace\Class;

would resolve into .../some/Deep/Namespace/Class.oj to be included in the build. But then again, we'd still have to implement a namespace mechanism. And that would complicate the compiler and make things more...problematic.

Anyway. Thanks for your insight on this! :)