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

Better ways to manage import names and aliases #100

Closed
xosmig opened this issue Dec 22, 2022 · 5 comments
Closed

Better ways to manage import names and aliases #100

xosmig opened this issue Dec 22, 2022 · 5 comments

Comments

@xosmig
Copy link

xosmig commented Dec 22, 2022

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 and file.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) and QualAlias(path, alias, name).

@dave
Copy link
Owner

dave commented Dec 22, 2022

You don't need to use ImportAlias or ImportName - if you don't use these, aliases will be assigned to each import automatically.

@xosmig
Copy link
Author

xosmig commented Dec 22, 2022

Sure, but the default aliases are not always good enough (which was, probably, the reason to introduce ImportAlias and ImportName in the first place). Especially in the context of code generation where it is, perhaps, relatively common to have many packages with the same folder name (e.g., foo/xyz, bar/xyz, baz/xyz).

UPD: sorry, the wording in my original message was misleading. I edited the message to make it clearer.

@xosmig
Copy link
Author

xosmig commented Dec 22, 2022

An alternative approach would be to make ImportAlias and ImportName types of *Statement.
Then they would be applied during the rendering (similar to how Qual itself is applied).

@xosmig
Copy link
Author

xosmig commented Dec 22, 2022

This can also potentially partially address #72

@dave
Copy link
Owner

dave commented Dec 22, 2022

not always good enough

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.

@dave dave closed this as not planned Won't fix, can't repro, duplicate, stale Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants