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

Proposal: better name for *ast.File fields #40058

Closed
amarjeetanandsingh opened this issue Jul 5, 2020 · 2 comments
Closed

Proposal: better name for *ast.File fields #40058

amarjeetanandsingh opened this issue Jul 5, 2020 · 2 comments

Comments

@amarjeetanandsingh
Copy link
Contributor

amarjeetanandsingh commented Jul 5, 2020

What version of Go are you using (go version)?

go version go1.13.4 darwin/amd64

What did you do?

The Package and Name fields of *ast.File struct are a bit confusing.

It was an effort just to get the name of Package of a *ast.Field object because I thought *.ast.File.Name will be the name of the file. It was so obvious that I didn’t though of looking at the comments.
Thanks to Rui Santos for helping me out. Later I saw it was written in comments Name is Package name, not the file name.

What did you expect to see?

  • Instead of Name, something like PkgName would be better because it contains the package name of that file.
  • Instead of Package, maybe PkgPos can be more helpful name because it contains token Pos.

What did you see instead?

  • *ast.File.Name field containing the package name of the file is not intuitive.
  • *ast.File.Package field contains a Pos of package, so it's difficult to understand .

If it's there, I guess there must be some reason to name those fields like that, what I am unaware of.
But it was confusing for me.

Even if we decide to rename the fields, i think it won’t be that straight forward because it will start breaking the older versions.

Please share your thoughts.

/cc @rsc @griesemer

@gopherbot gopherbot added this to the Proposal milestone Jul 5, 2020
@ianlancetaylor
Copy link
Contributor

They may be bad choices, but any change now would break the Go 1 compatibility guarantee (https://golang.org/doc/go1compat).

@davecheney
Copy link
Contributor

Based on 👍 from the OP closing as answered.

@golang golang locked and limited conversation to collaborators Jul 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants