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
Better ways to manage import names and aliases #100
Comments
You don't need to use |
Sure, but the default aliases are not always good enough (which was, probably, the reason to introduce UPD: sorry, the wording in my original message was misleading. I edited the message to make it clearer. |
An alternative approach would be to make |
This can also potentially partially address #72 |
The aim of jennifer is to produce correct code (e.g. code that compiles). Producing pretty code with your preferred formatting is a nice-to-have but not something I'll be complicating the API to facilitate. |
The way I understand it, with the current API, if you want to specify custom aliases or names, you need to know all packages that can potentially be imported in advance and use
file.ImportAlias
andfile.ImportName
.This, in a sense, defeats the whole purpose of having something like
Qual
, which is supposed to take care of package imports and spare the user from having to know them beforehand.A simple fix could be adding something like
QualName(path, pkgName, name)
andQualAlias(path, alias, name)
.The text was updated successfully, but these errors were encountered: