Namespace keyword

[sophiajt]

Now that we have ES6 modules in TypeScript, we should probably move towards a cleaner separation in the module types.

In truth, "internal modules" have been a bit of confusion for developers new to TypeScript. They're much closer to what most people would call a namespace.

Likewise, "external modules" in JS speak really just are modules now.

Let's move to a simpler explanation and have namespaces and modules be more separate. We'd still support the previous syntax, but this would mean introducing a new keyword called 'namespace' that was a bit easier to read and doesn't conflict with ES6 terminology.

Before:

module Math {
    export function add(x, y) { ... }
}

After:

namespace Math {
    export function add(x, y) { ... }
}

[nycdotnet]

Is this a keyword change only? For example, would clodules still be supported? (clamespaces?)

[DanielRosenwasser]

It's an additional keyword that does the same thing. To the best of my understanding from current discussions, module would be deprecated in favor of namespace.

"clamespaces", "funspaces", and other exciting possibilities of names are just a nice bonus. 😄

[NoelAbrahams]

I like this suggestion.

We could make this change more potent by accompanying it with the use keyword.

math.ts

namespace math {
    export function add(x, y) { ... }
}

foo.ts

/// <reference path='math.ts' />
var num = math.add(0, 1); // Error: Unknown reference 'math'


use namespace math;

var num = math.add(0, 1); // okay
var num = add(0, 1); // also okay

This shouldn't be a breaking change because the error is only raised when the namespace keyword is used to declare a "module".

At the moment we are forced to keep our namespaces relatively flat in order to avoid problems with accessing deeply nested types:

var foo = foo.bar.baz.bazooka.add(10,3);

[basarat]

I strongly support this. The number of times I've had to explain is insane. Thanks!

[Steve-Fenton]

👍

[mihailik]

A crucial expectation for namespaces is to span multiple declarations.

namespace Colors {
  export var Red = 'red';
}

namespace Colors {
  export var Green = 'green';
}

Here both Red and Green are heavily implied to be in the same namespace, as opposed to the second one extending the first.

Obviously, in JS/TS namespaces/internal modules actually create closures instead, see arguing about it on issue #447. This closure (and potentially an actual behaviour logic) doesn't quite fit with what 'namespace' implies. 'Module' is actually better.

module Colors {

  console.log('some work here...');

  export var Red = 'red';
}

module Colors {

  console.log('some other work here...');

  export var Green = 'green';
}

However 'module' can become confusing after ES6 gains wider adoption. How about 'namespace module' instead?

namespace module Colors {

  console.log('some work here...');

  export var Red = 'red';
}

That way it looks clearer to me. It still is havily hinting towards 'namespace modules' having behaviour, not just scope. But at the same time it's also clear those are some special modules, not your normal ES6 modules.

[sophiajt]

@mihailik Not sure exactly what you mean. Multiple namespaces would let you span multiple declarations, just as internal modules do today. The codegen extends the existing module if it's there, rather than create a new closure each time. The linked issue seems to be more about the codegen being suboptimal in some cases.

Unlike modules, which are based around a file and aren't extendable, namespaces (nee internal modules) are extendable. The only caveat is that closed-over non-exported symbols can't be seen across each namespace being merged, but I'd argue that's a good thing rather than a bad thing.

[Steve-Fenton]

@jbondc external modules are called "Modules" in ECMAScript 6, so it makes sense to stick with calling them "Modules" in TypeScript.

[mihailik]

@jonathandturner the question is not whether it's a good or bad thing -- the question is whether it's a naturally expected thing.

I'd say that 'namespace' suggests it's a syntactic construct, whereas 'module' suggests lifetime and behaviour.

[NoelAbrahams]

The objections to using namespace as the keyword seem rather academic from my point of view.

[nycdotnet]

"clamespaces", "funspaces", and other exciting possibilities of names are just a nice bonus.

I support this simply because of the possibility of funspaces.

[mihailik]

Great summary, @jbondc !

To me keeping 'module', but adding a qualifier makes most sense: clearer English, and greater backward and forward compatibility. Few more:

scope module Colors {
  export var Red = 'red8';
}

closure module Colors {
  export var Red = 'red9';
}

extend module Colors {
  export var Red = 'red10';
}

Beware the familiarity of 'namespace' appealing to C#-aware folks! That's not a wise move to gain a wider foothold in JS universe.

[NoelAbrahams]

I'm not quite following the arguments. So we don't want to introduce a new keyword, and we don't want to do C#-aware stuff, but nobody complained about async/await?!