[TS][Inversify] Rename map to GlobalImportOperators

[wing328]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Rename map to GlobalImportOperators so that map doesn't need to be a reserved word.

cc @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10)

[macjohnny]

this does not seem correct to me. I expect that this does not work

[wing328]

this does not seem correct to me. I expect that this does not work

@macjohnny How can we make it work? :)

What's the issue?

(I've not tested it locally)

[macjohnny]

@wing328 I don't understand the reason why map can't be a reserved keyword.

[macjohnny]

"rxjs/operators" does not export a GlobalImportOperators symbol

[wing328]

Ah I got it....

[wing328]

so we need something like

import * as GlobalImportOperators from "rxjs/operators";

and then call it by

GlobalImportOperators.map

(or something like that) ?

[macjohnny]

@wing328 I vote against renaming imported symbols and for making them reserved keywords, since I consider it a design flaw to simply insert arbitrary (user-defined) variable names into a code template. When simply renaming imports, there will always be a naming conflict, although someties less likely.

See also
#2921

[wing328]

When simply renaming imports, there will always be a naming conflict, although sometimes less likely.

Agreed the naming conflicts can still occur but should be less likely.

I'll close this PR as no one has complained about naming conflicts yet.

We'll revisit this when there are more demands from the users to name their variables or models as "map" or other reserved words.