I am sure that I understand all this export stuff with packages - it’s pretty obvious - if it starts with capital letter, one can use it from outside the package (is it type or func/method or struct field).
But when it comes to main package - I have know idea what’s the point of exporting from main since all types/funcs etc. declared in main are visible from it, no matter how many files it comprises.
As for testing - check out this comment. If you substitute “Hello” with “hello” in both files, everything still works fine.
In the meantime, e.g., go tool sources contains exported and unexported types and funcs.
Isn’t this the same as having a package with multiple files, also being able to access it’s own unexported fields? (Unless I misunderstand what you’re saying)
Either way, one thing that comes straight to mind is the fact that for things such as encoding, you won’t be able to encode anything unexported.
One other thing to note is that the main package should really be used as an entry point, not some massive collection of files, so really I don’t see too many times where you would have that many main package files unless you are not really packaging things well. (Don’t get me wrong this is just my opinion since I’m no expert)
There is no practical difference as you can’t importpackage main from anywhere else. That said, when writing a type I find that it’s still useful to consider what methods etc would be exported, if the type were in a different package. This clarifies the API and makes it a little bit easier if the type is ever refactored away to a different package. An unexported type with only unexported methods gives off a strong “internal utility type only” vibe. But it’s really just a matter of taste.
Couldn’t answer that really… Like I said anyway, the above was just my opinion and there are definitely people here that have better answers, but just thought I’d give ya my take on the matter.
I would probably say it’s written the way it is, because it is just a massive tool, but still just a single huge command and there wouldn’t be benefit to splitting it up the way you would with other packages since nothing else is going to be importing it.
This is pretty much my way of saying that I have no clue but am trying to make sense from it myself
Also, everyone does things differently, so I think comparing the docker team to the Go team is comparing apples to oranges lol
I reckon that’s probably it I’m really not familiar with most of that stuff anyway and I think Jakob’s probably a lot smarter than I am anyway so lets just stick with his answer
If there was any technical reason, I’m sure someone like @dfc would know if he sees this.
I don’t think there is a strong reason to suggest one or the other. You cannot import a main package, except in the case of package main_test in the same file. That is an external test of your main package. This is a pretty specialised case and for the first two releases of Go it didn’t even work.
Recently I wrote a small main package for a blog article, and I made some of the functions uppercase because I plan to move them into a library for the next blog post.
Sometimes the reason for uppercase functions in main can be as simple as that.
