unify namespaces and objects

[zpdDG4gta8XKpMCd]

Namespaces are objects that can hold types, but cannot be passed around because don't have a type themselves.
Objects are mostly namespaces which can be passed around because they are typed, but cannot hold types in them.

Looks like this difference is a made up thing.

Consider unifying objects and namespaces.

possible resolution of #8308

[mhegazy]

so what is the proposal? and how is it different from #8308?

[zpdDG4gta8XKpMCd]

proposal goes: make namespaces first class citizens, which is

• make it possible to close them over types and values from a current scope
• return from a function
• pass as a parameter

they are different in a scope of work, #8308 is (hopefully) less work and because of that might win over this request

[mhegazy]

pass as a parameter

i am guessing you mean define a parameter as a namespace, you can pass them now just fine.

[zpdDG4gta8XKpMCd]

not sure what you mean:

namespace N {
    type T = string;
}

function f(n: typeof N) { // <-- ?
    return <n.T> undefined;
}

[mhegazy]

the value N (the object literal equivalent) does not exist. so typeof N is nothing. namespace N { export var x; } has a type and it is { x: any }.

[mhegazy]

I still do not see much difference and/or proposals than #8308. i would rather have one issue.

[zpdDG4gta8XKpMCd]

which one is more likely to be implemented this (unifying objects and namespaces) or #8308 (adding types as pseudo-properties of objects)?

...does not exist. so typeof N is nothing

can you show an example of passing a namespace as an argument?

[mhegazy]

namespace N {
    export var x = 0;
}

function f(n: typeof N) {
    return
}

f(N) // OK
f({ x: 0 }); //OK


function f2(n: { x: number }) {
    return
}

f2(N) // OK
f2({ x: 0 }); //OK

[zpdDG4gta8XKpMCd]

i am talking about this

[mhegazy]

OK, so there is a value, i.e. the entity that exists at runtime in JS, there is a type, i.e. the design time construct that is defined in a TS file, and there is a namespace, something that can contain, values, types and other namespaces.

a name can have 1, 2, or all 3 meanings based on its declaration. so a class is both a type and a value. an enum, is a value, a type, and a namespace, etc..

you can read more about this at: http://www.typescriptlang.org/docs/handbook/declaration-merging.html

typeof value returns the type of a value. a namespace can not have a type. just cause it does not make much sense. in the example above, T is a type, it is not a property on the value N, it is just another type that is accessed using the name N.T.

this is what i meant by askign for a proposal on how this would fit in the existing design in #8308 (comment)

I think the two issues are the more or less the same issue, and a clear and detailed proposal is needed. marking this issue as a duplicate.

[zpdDG4gta8XKpMCd]

i am closing the other one (#8308) then

[DanielRosenwasser]

#420 seems vaguely related for the record.

The thing is that there is no value side to non-instantiated namespaces. Something like

namespace n {
    export interface Foo { }
}

doesn't actually have any associated emit, so it's not clear what you'd pass in for a function like

function foo(x: typeof n) {
    // ...
}

Does

foo(n);

compile to the following?

foo(undefined);

[zpdDG4gta8XKpMCd]

practically (as far as i know it) i only pass types and values (never types alone), although it is a valid question, need to find a use case that does it

[zpdDG4gta8XKpMCd]

side note, you don't need to pass types-only namespace, you can make it on site as you want:

    declare namespace HiThere<A, B, C> {
    }

    type NamepsceWithTypesThatINeed = HiThere<string, boolean, number>;