
Golang 1.4 Internal Packages - signa11
http://golang.org/s/go14internal
======
jlouis
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.

~~~
chrismonsanto
> 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!

~~~
levosmetalo
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.

~~~
MichaelGG
I had no idea. Why do so many projects setup these crazy directory trees for
source then?

~~~
levosmetalo
Because it allows you to have your User.java class in both com.comp.ldap and
com.comp.db packages.

------
frou_dh
Magic directory names seems a bit of a hack to avoid supporting this notion in
the language itself.

AFAIK this also introduces the English language into the currently freeform
world of user import paths. I guess source files themselves already have
something similar with the "_test.go" suffix, so there's some consistency with
that.

~~~
bwooce
What magic directory names? The special case for "pkg" is the only one I saw.

The main proposal is one of scoping by directory hierarchy - /a/b/c can import
a/b/d but a/g/x can't.

~~~
lloeki
> What magic directory names?

"internal"

> The main proposal is one of scoping by directory hierarchy - /a/b/c can
> import a/b/d but a/g/x can't.

/a/b/c can import a/b/d, and /a/g/x and /z can too. The new rule is that
/a/g/x can not import /a/internal/y.

~~~
sltkr
> The new rule is that /a/g/x can not import /a/internal/y.

As I understand it, /a/g/x CAN import /a/internal/y, because /a/g/x is in the
directory tree that starts at /a/. However, /b/h/z CANNOT import
/a/internal/y/ (while previously, it could).

------
blackRust
The way ML modules works seems to me like a much better deal: with interfaces
and implementations. There's a proposal to have something similar done to
Haskell.

[1] [http://plv.mpi-sws.org/backpack/](http://plv.mpi-sws.org/backpack/)

~~~
pjmlp
Just like most module based languages.

What ML modules have as extra advantage over other module systems, is that
they also exist as types.

------
coldtea
> _There is unexported code duplicated in the standard library because sharing
> it would have required exporting those functions: net /http and
> net/http/httputil share a few parsing functions, and there are four ‘func
> itoa’ in various packages. Similarly, cmd/nm and cmd/objdump contain the
> same file reading code._

This is so basic and has been solved by other languages so long ago that it's
quite strange to see Go had to reach 1.4, and 5+ years of age to get this...

...and in quite an ad-hoc and hackish way -- which means you're tied to a
directory hierarchy.

~~~
georgemcbay
You say ad-hoc and hackish, I say simple and practical.

~~~
coldtea
Simple is not always good.

As the quote (attributed to Einstein IIRC) goes: "You must strive to make
things as simple as possible -- but no simpler than that".

This is, I think, something "simpler" than simple ("simpleton"?).

------
kyrra
The discussion[0] on the golang-dev for this proposal is getting the most
discussion out of of any of the proposed features. Most of it are people
asking for addtions to the feature that would change/add-to the language
syntax (which isn't allowed in Go 1.x) or changing the 'internal' directory
name to something else.

[0] [https://groups.google.com/forum/#!topic/golang-
dev/_cAggq73y...](https://groups.google.com/forum/#!topic/golang-
dev/_cAggq73yME)

~~~
BarkMore
Backwards compatible changes to the language is allowed in Go 1.x.

------
infogulch
I find this solution very Go-like. Akin to other name-dependent features like:
Exported functions and types in a package start with a capital letter. Test
functions are in '*_test.go' files. Simple and practical, with only one way to
do it.

~~~
coldtea
> _I find this solution very Go-like._

As in "without deep thought", "ho-hum" and 30 years below the state of the
art?

------
politician
The Go spec has always indicated that package import paths are opaque strings,
and that the semantics of interpreting those paths is performed by the go
tool.

That said, transforming the package import path into a half-assed file system
query language slash dependency management solution is a source of frustration
for a problem that has been elegantly solved by DNS.

I would love if the Go team redefined package import paths as strings to be
resolved by go-dns -- an imaginary package name resolution tool which looks up
package imports by resolving paths via records stored in package, workspace,
and upstream "nameservers".

Or, you know, use Godeps.

------
gioele
Isn't this similar to the ancient "private protected" visibility level [1] of
Java?

[1]
[http://everything2.com/title/private+protected](http://everything2.com/title/private+protected)

------
pjmlp
Nice to see Go adopting the subpackage/module notion of other module based
languages.

------
bwilliams
I sound like a broken record, but Golang is totally worthless to me until
$GOPATH is abandoned. I don't want everything down to my workspace structure
determined for me. Once that's done with I think Go would be an amazing
language to use.

~~~
Jayschwa
I'm a borderline Go fanboy, but GOPATH tends to drive me nuts as well. It'd be
nice if it had a sane default. 99% of the time, I'm just doing GOPATH=$PWD.

~~~
artursapek
I'm glad I'm not the only one confounded by GOPATH. I have a script I use to
build my files that does

    
    
        GOPATH=`pwd`:$GOPATH go build $1.go
    

...where my bash_profile initially exports GOPATH as /usr/local/go. Probably
unconventional but hey, it works.

