On Tue, Oct 24, 2017 at 10:02 PM, Alex Buchanan <bucha...@ohsu.edu> wrote:
> Interesting, thanks. Let me try to clarify my idea with some simple code:
>
> // file lives at github.com/buchanae/foobar/foobar.go
> package foobar
>
> func Foobar() string {
> return "foobar"
> }
>
> func main() {
> print(Foobar())
> }
>
> This file exports both a function to be used as a library, and a main
> function which would be compiled into a command line utility. In order to use
> the library, you'd write `import "github.com/buchanae/foobar";
> foobar.Foobar()`. In order to use the command line tool, you'd run `go get
> github.com/buchanae/foobar` and run `foobar` on the command line. There's no
> `import "main"` or package named main in this example. The compiler would
> need to look for a main function in the starting package and perhaps name
> symbols using the fully qualified package name. Also, packages in the
> "foobar" tree would not be importing the root, so there are no import cycles.
>
> I'm not sure it's a good idea, but it was my instinct when I started writing
> Go, and feels like it would have simplified the organization and
> documentation of some projects which have a separate "go get <url>" for the
> library vs the CLI command.
Personally I think it's better to separate the library and the
command. That is particularly true if the command takes any flags.
> Hope that made sense. Probably too late to be writing about such things :)
Indeed. It's an interesitng idea but this isn't something that is
going to change at this point.
Ian
> On 10/24/17, 9:31 PM, "Ian Lance Taylor" <i...@golang.org> wrote:
>
>>On Tue, Oct 24, 2017 at 8:14 PM, Alex Buchanan <buchanae.o...@gmail.com>
>>wrote:
>>>
>>> Is there documentation (or other) explaining why the main package must have
>>> name "main" and may not be imported? Is this an important simplification for
>>> the compiler?
>>
>>The language spec says that the main package must have the name main.
>>I guess we could use other mechanisms but that one seems reasonable to
>>me.
>>
>>cmd/compile prohibiting `import "main"` is a moderately important
>>simplification because cmd/compile uses the import path to set symbol
>>names, and for the main package it uses "main". If cmd/compile
>>permitted `import "main"` then there would be two different packages
>>with the same import path, which can't work. So it would have to use
>>something else for the imported "main", but what?
>>
>>Note that cmd/compile does not prohibit importing a package named
>>"main" if the path used to import that package is not specifically
>>"main". But I think the go tool does prohibit that, and I think that
>>is simply to be less surprising to most people.
>>
>>Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
