7 ms·

It would seem the important feature of a modern language is how it handles modularization. The ability to program-at-large requires a language to make trade-off

by jlouis 12y ago

It would seem the important feature of a modern language is how it handles modularization. The ability to program-at-large requires a language to make trade-offs here and there. I do note that the Go-centric world would naturally make the file system part of the language. Its plan9 heritage makes this very easy. I also note that this is a mistake in language design. Packages and modules should never be reliant under an assumption about the underlying file system, as it tend to lock languages to certain platforms.

lloeki 12y ago
Had the Go team made an assumption, they may have leveraged filesystem case-sensitiveness (or rather, case preservation†) to follow the same rule as for package exports: capitalised => exported, lowercase first => not exported. The only assumption here is that the filesystem supports a tree. † This means any current filesystem except FAT which has (had?) a habit of changing the case of same-cap names in one way or the other. Cap-changing renames are a chore on some systems though.
chrismonsanto 12y ago
> Packages and modules should never be reliant under an assumption about the underlying file system, as it tend to lock languages to certain platforms. And it gives you an escape hatch from Java-style module nonsense: of COURSE I want to traverse 7 singleton directories to get to the source code!
- richardwhiuk 12y ago
  That would be a simple fix to be honest - and one that Java 8 could make without backward compatibility issues. Simply allow the hierarchy to be short cutted if a directory contains the a dot separated name e.g instead of com/foobar/bar/module/a/b allow com.foobar.bar.module/a/b
- pjmlp 12y ago
  Which happens to be shared by other languages as well.
- levosmetalo 12y ago
  Java allows you to put all your source files in one directory and javac *.java will happily compile them. Package-directory structure applies only for compiled classes and internal content of a jar file. For Java sources, that is just a convention. But of COURSE, it is so modern to blame Java for everything these days.
  - taf2 12y ago
    Blaming java is nothing new.
  - MichaelGG 12y ago
    I had no idea. Why do so many projects setup these crazy directory trees for source then?
    - levosmetalo 12y ago
      Because it allows you to have your User.java class in both com.comp.ldap and com.comp.db packages.
- lobster_johnson 12y ago
  I believe Java will behave sanely with regard to source directories. If you have a file Foo.java declaring itself as "package x.y.z", then it can happily live as "src/Foo.java". It's only when you try to run the thing that the JVM will complain (with the rather unhelpful error message "wrong name: x/y/z/Foo"). So if your build process builds the correct folders and stores the .class files there, it's going to work. (Not that it's very useful; after all, your build system would have to know where to put everything.)
  - rem7 12y ago
    The fact that we are comparing all of this with java makes me so sad.
dsymonds 12y ago
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.
4ad 12y ago
> Packages and modules should never be reliant under an assumption about the underlying file system They are not. Import paths are not part of the language, they are interpreted by the go tool. The only relation to the filesystem is that by using the go tool, you will get a directory hierarchy that seems to match import paths in the sense that that in foo/bar you will have a bar directory child to a foo directory. This is very useful to developers, it means they can find their files, but you could build a conforming build tool that keeps files in SQL, if that's your thing.

by jlouis 12y ago

lloeki 12y ago

Had the Go team made an assumption, they may have leveraged filesystem case-sensitiveness (or rather, case preservation†) to follow the same rule as for package exports: capitalised => exported, lowercase first => not exported. The only assumption here is that the filesystem supports a tree. † This means any current filesystem except FAT which has (had?) a habit of changing the case of same-cap names in one way or the other. Cap-changing renames are a chore on some systems though.

chrismonsanto 12y ago

> Packages and modules should never be reliant under an assumption about the underlying file system, as it tend to lock languages to certain platforms. And it gives you an escape hatch from Java-style module nonsense: of COURSE I want to traverse 7 singleton directories to get to the source code!

richardwhiuk 12y ago
That would be a simple fix to be honest - and one that Java 8 could make without backward compatibility issues. Simply allow the hierarchy to be short cutted if a directory contains the a dot separated name e.g instead of com/foobar/bar/module/a/b allow com.foobar.bar.module/a/b
pjmlp 12y ago
Which happens to be shared by other languages as well.
levosmetalo 12y ago
Java allows you to put all your source files in one directory and javac *.java will happily compile them. Package-directory structure applies only for compiled classes and internal content of a jar file. For Java sources, that is just a convention. But of COURSE, it is so modern to blame Java for everything these days.
- taf2 12y ago
  Blaming java is nothing new.
- MichaelGG 12y ago
  I had no idea. Why do so many projects setup these crazy directory trees for source then?
  - levosmetalo 12y ago
    Because it allows you to have your User.java class in both com.comp.ldap and com.comp.db packages.
lobster_johnson 12y ago
I believe Java will behave sanely with regard to source directories. If you have a file Foo.java declaring itself as "package x.y.z", then it can happily live as "src/Foo.java". It's only when you try to run the thing that the JVM will complain (with the rather unhelpful error message "wrong name: x/y/z/Foo"). So if your build process builds the correct folders and stores the .class files there, it's going to work. (Not that it's very useful; after all, your build system would have to know where to put everything.)
- rem7 12y ago
  The fact that we are comparing all of this with java makes me so sad.

dsymonds 12y ago

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.

4ad 12y ago

> Packages and modules should never be reliant under an assumption about the underlying file system They are not. Import paths are not part of the language, they are interpreted by the go tool. The only relation to the filesystem is that by using the go tool, you will get a directory hierarchy that seems to match import paths in the sense that that in foo/bar you will have a bar directory child to a foo directory. This is very useful to developers, it means they can find their files, but you could build a conforming build tool that keeps files in SQL, if that's your thing.