multiple packages in the same folder and package keyword useless now?

[Rodrigo Kochenburger]

Hey,

Now that the go tool requires each directory to be one package and doesn't allow to have files with different package names inside the same folder, how is the package keyword useful? It seems like a unnecessary repetition.

Is it required by the compiler or is there any plan to remove it?

Also, since we don't have relative imports anymore would it make sense to allow having different packages in the same folder and allow importing them? At least this way you could break down your app in packages with access control to it's elements (public/private methods, structs, etc).

[Jesse McNelis]

On Thu, Mar 22, 2012 at 1:30 AM, Rodrigo Kochenburger <div...@gmail.com> wrote:
> Now that the go tool requires each directory to be one package and doesn't
> allow to have files with different package names inside the same folder, how
> is the package keyword useful? It seems like a unnecessary repetition.
> Is it required by the compiler or is there any plan to remove it?

The package declaration declares the name of the package.
The language Go doesn't know what a file or a directory is and the
import path itself doesn't effect the actual name of the package that
is being imported. So the only way the compiler knows what to call the
package is the package declaration.

> Also, since we don't have relative imports anymore would it make sense to
> allow having different packages in the same folder and allow importing them?
> At least this way you could break down your app in packages with access
> control to it's elements (public/private methods, structs, etc).

Packages are usually fairly large, much larger than a class in Java
etc. If you feel that making a directory is overkill for your package
then it's likely you've split your project up in to too many packages.

--
=====================
http://jessta.id.au

[chris dollin]

On 21 March 2012 14:30, Rodrigo Kochenburger <div...@gmail.com> wrote:
> Hey,
>
> Now that the go tool requires each directory to be one package and doesn't
> allow to have files with different package names inside the same folder, how
> is the package keyword useful?

Yes.

> It seems like a unnecessary repetition.

You don't always come across files embedded in their directories.
It's nice to be able to look inside the file and see what package it
belongs to.

> Is it required by the compiler

It's part of the grammar.

> or is there any plan to remove it?

I've not noticed any, and it would, absent actual problems that removing
it would solve, seem to be ... unproductive. Also I think it would break
the Go1 stability contract.

> Also, since we don't have relative imports anymore would it make sense to
> allow having different packages in the same folder and allow importing them?

Why make things complicated when they're already simple?

> At least this way you could break down your app in packages with access
> control to it's elements (public/private methods, structs, etc).

You already can. Just put the different packages in different directories.

(Or did you mean to suggest having levels of visibility other than
unexported / exported? I rather like Go's binary visibility rule. Not
entirely convinced by the capitalisation, but the binary rule, that's
nice.)

Chris

--
Chris "allusive" Dollin

[Rodrigo Kochenburger]

I like the binary rule as well. It just seems to me that disallowing relative imports and not allowing multiple packages in the same directory discourage people to structure the projects in subpkgs.

But I don't wanna start the whole relative import fight, I was just wondering if the keyword was important because now it seems redundant to me.

Rodrigo Kochenburger

[Peter Bourgon]

On Wed, Mar 21, 2012 at 3:56 PM, Rodrigo Kochenburger <div...@gmail.com> wrote:
> I like the binary rule as well. It just seems to me that disallowing
> relative imports and not allowing multiple packages in the same directory
> discourage people to structure the projects in subpkgs.

Yes, generally one project == one repo == one package is best
practice. Packages are not namespaces.

[Rodrigo Kochenburger]

This make a lot of sense when developing libraries, but doesn't make much sense to me when you're developing a big application when you might have different domain aspects and/or implementation grouping that you'd like to separate and isolate to reduce coupling.

Rodrigo Kochenburger

[Peter Bourgon]

"Separation to reduce coupling" and "using different packages" are
orthogonal actions. You can do the former without doing the latter.

"Splitting into different packages" and "Splitting into different
repositories" are (more) closely aligned.

[chris dollin]

On 21 March 2012 15:03, Peter Bourgon <pe...@bourgon.org> wrote:>
> Yes, generally one project == one repo == one package is best
> practice.

Bleagh.

Max of one repo per project I can sort of see, but I don't see why
there shouldn't be multiple projects based in one repo, to reduce
repo clutter if nothing else, and one package for an entire project?
That seems to me to be bonkers. I suspect we have strongly
different notions of how "big" a package or project is and how stronly
connected they are (or not) internally.

EG to pick a random hypothetical example, if one were hacking up
some Go tools to handle RDF, one would want a Turtle reader
(because RDF/XML is horrid) and one would want a NTRIPLES
writer (because that's the standard for test cases) and one would
want some base RDF stuff about IRIs and literals and whatnot and
at least one implementation of a graph thingy, and it seems to me
that they would certainly all belong in different packages and they
certainly wouldn't all deserve to be projects with their own repos.

For some value of "certainly".

> Packages are not namespaces.

Well, they /are/ namespaces. They're not /only/ namespaces.

[Stefan Nilsson]

"One project == one package" may not be the best advice. Take a look at

crypto and its subdirectories (in two levels, no less). Putting all of this

in one namespace would have been a major headache. In fact, Effective

Go suggests using packages as namespaces:

"The importer of a package will use the name to refer to its contents (the import . notation is intended mostly for tests and other unusual situations and should be avoided unless necessary), so exported names in the package can use that fact to avoid stutter. For instance, the buffered reader type in the bufio package is calledReader, not BufReader, because users see it as bufio.Reader, which is a clear, concise name. Moreover, because imported entities are always addressed with their package name, bufio.Reader does not conflict with io.Reader."

[Peter Bourgon]

> In fact, Effective Go suggests using packages as namespaces:

No, it states that you can leverage the fact that packages are
explicitly "namespaced" (more like "qualified") to make your public
identifiers succinct.

That said, after re-considering eg. crypto and vitess, and refreshing
"go build" behavior, I'll agree that for large projects, multiple
packages in one repository can make sense. But (to save a bit of face
:) --

> not allowing multiple packages in the same directory
> discourage people to structure the projects in subpkgs.

A subpkg certainly ought to be in its own [sub]directory.

[Rodrigo Kochenburger]

Yes, I agree that a subpkg is better in a subdir. But then back to what started the conversation, why do we have the package keyword if it can be inflected from the subdir and why cant we have relative import, at least to subdirs (i.e. not alowing ..)

Anyway, those discussions have been happening for a while but doesn't seem to go anywhere :)

Rodrigo Kochenburger

[Paul Borman]

package main

[Ethan Burns]

On Wednesday, March 21, 2012 12:16:39 PM UTC-4, Rodrigo Kochenburger wrote:

Yes, I agree that a subpkg is better in a subdir. But then back to what started the conversation, why do we have the package keyword if it can be inflected from the subdir and why cant we have relative import, at least to subdirs (i.e. not alowing ..)

The language doesn't require separate packages to be in separate directories; it is a requirement of the go tool.  Another hypothetical implementation may not have this requirement.  Additionally, people building with Makefiles, 6c, and friends do not have this restriction; they are free to have as many packages in a single directory as they like.

Ethan

[minux]

Even this go tool requirement can be bypassed thanks to the "// +build" build tags.

For example, read misc/cgo/gmp or misc/cgo/stdio

[Johann Höchtl]

How so? // +build ignore    ignores, what is the further use to be able to specify a package name, which would be ignored anyway?

[DisposaBoy]

On Wednesday, March 21, 2012 4:16:39 PM UTC, Rodrigo Kochenburger wrote:

Yes, I agree that a subpkg is better in a subdir. But then back to what started the conversation, why do we have the package keyword if it can be inflected from the subdir

because it can't, I said this in response to the last post asking pretty much the same thing so i'l repeat: you *can* have multiple packages in the same directory...

[minux]

'go build' will build "ignored" code happily, and this is a feature, I think.

[André Moraes]

> Yes, I agree that a subpkg is better in a subdir. But then back to what
> started the conversation, why do we have the package keyword if it can be
> inflected from the subdir and why cant we have relative import, at least to
> subdirs (i.e. not alowing ..)
>
> Anyway, those discussions have been happening for a while but doesn't seem
> to go anywhere :)
>

go get github.com/kuroneko/go-sqlite3

import (
"github.com/kuroneko/go-sqlite3"
)

func main() {
sqlite3.DoSomething()
}

In this case, the name of the package cannot be in any way, the name
of the subdir, since go-sqlite3 isn't a valid go identifier. That's on
reason for having the package statement.

Consider this:
The import path is the location where you get some package,
The package stmt is the name that the author desired for his package.

If you have two different versions of the same package you can change
only the import path and not the package name, making them coupled
would break this. Also, you can always create a alias for packages.

--
André Moraes
http://andredevchannel.blogspot.com/

[Rodrigo Kochenburger]

"Separation to reduce coupling" and "using different packages" are
orthogonal actions. You can do the former without doing the latter.

Well if I can only define access control/exposure of elements (functions, structs, etc) on a package basis, it definitely helps decoupling parts of the app.

"Splitting into different packages" and "Splitting into different
repositories" are (more) closely aligned.

If you ever worked on a big project, you know that have separate components inside the app (even for the domain part) makes the application easier to maintain. I don't want to break one app in different respositories just to have separate packages, that is insane.

[John Asmuth]

The thing to do here would be to break it into multiple files, not multiple packages.

If a set of files are always/only compiled with each other, they should be in one package.