Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "import *" like Python #2819

Closed
cnshenj opened this issue Apr 17, 2015 · 13 comments
Closed

Add "import *" like Python #2819

cnshenj opened this issue Apr 17, 2015 · 13 comments
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript

Comments

@cnshenj
Copy link

cnshenj commented Apr 17, 2015

Sometimes a class/function has a few supporting small types, like the example below.
In foo.ts:

interface IOptions {...}
interface IResult {...}
function foo(options: IOptions): IResult {...}
export = foo;

Then in another file:

import foo = require("foo");
var options: IOptions = {...};
var result = foo(options);

This doesn't work because IOptions and IResult have be exported too. But then you'll have to write:

import fooMod = require("foo");
var options: fooMod.IOptions = {...};
var result = fooMod.foo(options);

It's also possible to put IOptions and IResult in separate files. But those two types are small and tightly coupled to foo, so it's easier to maintain them in the same file as foo. Also, you'll need to write 3 import statements to import them all.

Why not support the following (like Python's from module import *)?
In foo.ts:

export interface IOptions {...}
export interface IResult {...}
export function foo(options: IOptions): IResult {...}

Then in another file:

import * = require("foo");
var options: IOptions = {...};
var result = foo(options);
@mhegazy
Copy link
Contributor

mhegazy commented Apr 17, 2015

With ES6 module syntax support you can write it as:

import  { foo, IOptions } from "foo";
var options: IOptions = {...};
var result = foo(options);

@cnshenj
Copy link
Author

cnshenj commented Apr 17, 2015

Seems the ES6 module syntax is only supported by TypeScript 1.5, which is not released yet?

@mhegazy
Copy link
Contributor

mhegazy commented Apr 17, 2015

TypeScript 1.5-alpha has been released, see https://github.com/Microsoft/TypeScript/releases/tag/v1.5.0-alpha for more details.

@danquirk danquirk added the Suggestion An idea for TypeScript label Apr 17, 2015
@nippur72
Copy link

@mhegazy but you still have to provide a list of names/aliases which is annoying if you have a file with lot of definitions. Instead it would be very useful to support a * syntax like this:

import { * } from "file";

Ideally the best syntax would be:

import "file";

but as I see from #2242 it's already taken for "Bare Imports".

Allowing import of whole files is a well established pattern (for example) in the Dart language.

@mhegazy
Copy link
Contributor

mhegazy commented Jul 25, 2015

The only issue with import * from "file" is it breaks single file transpilation scenarios. and prevents modules from being statically-analyzable, one of the design vectors the committee stressed.

@nippur72
Copy link

@mhegazy it doesn't have to be different from what TypeScript is actually doing now.

To be more clear, my suggestion is that:

import { * } from "file";      // notice curly braces

to became a shortcut for

import { foo,bar } from "file";

Its only purpose should be to avoid to re-type names; it should not introduce any new behaviour.
In other words, it would scan "file" looking for exported symbols and put in place of the *.

@teppeis
Copy link

teppeis commented Jul 26, 2015

@nippur72
As @mhegazy mentioned, it breaks single file transpilation scenarios.
TypeScript should use ES Modules spec syntax. It considers most of scenarios.

@nippur72
Copy link

@teppeis if import { * } breaks single-file-transpilation scenarios, then import { foo,bar } does too (assuming that * would be replaced by the list of exported names). What am I missing?

@mhegazy
Copy link
Contributor

mhegazy commented Jul 26, 2015

The idea is that you can process a module in isolation, without knowing anything about other modules..

in cases where you want the compile to bring all bindings in scope using import * from mod" this is not possible. consider:

import * from "mod1";
import * from "mod2";

a;

we do not know if a referes to mod1.a or mod2.a, or a global a. the only way the compiler can resolve these is by understanding all exported bindings from mod1, mod2, and the global scope. thus breaking single module transpilation..

i understand this is a useful feature, TypeScript already supports something similar with namespaces where nested namespaces do not need to fully qualify access to exported members. However, breaking the module transpilation would block a large set of tools and workflows that other users find useful.

@nippur72
Copy link

@mhegazy thank you for the example, now it's more clear what is meant by "breaks single file scenarios".

If the goal is avoiding scanning external files, then it makes sense to be forced to explicitly list names.

@kitsonk
Copy link
Contributor

kitsonk commented Jul 27, 2015

If the goal is avoiding scanning external files, then it makes sense to be forced to explicitly list names.

How do you scan files when you are transpiling client side? It isn't a goal, it is a technical reality in some environments.

@mhegazy
Copy link
Contributor

mhegazy commented Dec 9, 2015

As mentioned in #2819 (comment), the original issue should be handled by ES6 module syntax.

@mhegazy mhegazy closed this as completed Dec 9, 2015
@mhegazy mhegazy added the Fixed A PR has been merged for this issue label Dec 9, 2015
@mhegazy
Copy link
Contributor

mhegazy commented Dec 9, 2015

the import * from "mod" request is tracked by #2956

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

6 participants