3 ms·

This is not a language change. It is a new convention enforced by a standard build tool. The compilers/linkers are not affected, nor is the language specificati

This is not a language change. It is a new convention enforced by a standard build tool. The compilers/linkers are not affected, nor is the language specification.

regularfry 12y ago
And I think that's jlouis' point, that internal packages could and should have been implemented at the language level, not the tool level.
- jlouis 12y ago
  Indeed. This is done better and with more care in Standard ML.
- ecnahc515 12y ago
  Given that a package can consist of multiple files, how do you purpose to do that? Each file in a package declares "package namegoeshere" at the top, so you would need to add a keyword to every file, or have some very confusing/weird behavior of partially unexposed/exposed packages.
politician 12y ago
Yes, the restricted macro preprocessor known as the go tool is not part of the language, but like the compilers and links it is part of the Go toolchain. The proposed changes are onerous because integrating with the toolchain to enable this feature requires changes to source code. Moreover, the proposed change is so very tied to a specific toolchain feature that it is likely that as the Go team encounters new package dependency management issues that they will continue to propose these micro tweaks to package import paths which require the rest of us to run around touching every source file.
- dsymonds 12y ago
  "Onerous"? Of all the Go source code on GitHub, there was only one place where an /internal/ path component wouldn't have the desired effect of this change. If you're talking about using this feature with existing code, renaming a directory is not a hard operation.
  - politician 12y ago
    The Go language specification states that the package import path is an opaque token. The Go team has decided to interpret that as an opportunity to interpret these tokens as an expression language with the following capabilities: locate packages on the filesystem, locate packages from some specific version control systems, (proposed) control how packages are compiled. My beef with this change is two-fold. First, why is there no specification for the package import path when there is plain, obvious, and necessary information encoded in this opaque token. Second, why is expediency a good justification for including compiler control flags in this undefined, unspecified opaque token. If the package import path is going to be used like this, then it should be standardized in the language specification.
    - dsymonds 12y ago
      The answer to your first beef is that it would complicate the specification unnecessarily. You would suddenly have to provide a lot more details in the language spec, such as defining what capabilities a filesystem must provide, environment variables, OS and architecture details, package formats, compiler invocation syntax, and so on. That's all taken care of by the go tool right now, and doesn't burden other compiler implementations with all that. Expediency is not used as a justification for this at all. You're wrong that any compiler control flags get involved here; 6g is going to be invoked with exactly the same syntax, and doesn't get told anything about "internal", just as it isn't told anything about build tags, or OS/arch-specific filename control (e.g. foo_linux.go).

This is not a language change. It is a new convention enforced by a standard build tool. The compilers/linkers are not affected, nor is the language specification.

regularfry 12y ago

And I think that's jlouis' point, that internal packages could and should have been implemented at the language level, not the tool level.

jlouis 12y ago
Indeed. This is done better and with more care in Standard ML.
ecnahc515 12y ago
Given that a package can consist of multiple files, how do you purpose to do that? Each file in a package declares "package namegoeshere" at the top, so you would need to add a keyword to every file, or have some very confusing/weird behavior of partially unexposed/exposed packages.

politician 12y ago

Yes, the restricted macro preprocessor known as the go tool is not part of the language, but like the compilers and links it is part of the Go toolchain. The proposed changes are onerous because integrating with the toolchain to enable this feature requires changes to source code. Moreover, the proposed change is so very tied to a specific toolchain feature that it is likely that as the Go team encounters new package dependency management issues that they will continue to propose these micro tweaks to package import paths which require the rest of us to run around touching every source file.

dsymonds 12y ago
"Onerous"? Of all the Go source code on GitHub, there was only one place where an /internal/ path component wouldn't have the desired effect of this change. If you're talking about using this feature with existing code, renaming a directory is not a hard operation.
- politician 12y ago
  The Go language specification states that the package import path is an opaque token. The Go team has decided to interpret that as an opportunity to interpret these tokens as an expression language with the following capabilities: locate packages on the filesystem, locate packages from some specific version control systems, (proposed) control how packages are compiled. My beef with this change is two-fold. First, why is there no specification for the package import path when there is plain, obvious, and necessary information encoded in this opaque token. Second, why is expediency a good justification for including compiler control flags in this undefined, unspecified opaque token. If the package import path is going to be used like this, then it should be standardized in the language specification.
  - dsymonds 12y ago
    The answer to your first beef is that it would complicate the specification unnecessarily. You would suddenly have to provide a lot more details in the language spec, such as defining what capabilities a filesystem must provide, environment variables, OS and architecture details, package formats, compiler invocation syntax, and so on. That's all taken care of by the go tool right now, and doesn't burden other compiler implementations with all that. Expediency is not used as a justification for this at all. You're wrong that any compiler control flags get involved here; 6g is going to be invoked with exactly the same syntax, and doesn't get told anything about "internal", just as it isn't told anything about build tags, or OS/arch-specific filename control (e.g. foo_linux.go).