Nesting packages, is it possible?

[Dave B.]

Is it possible to nest packages, Similar to c++ namespace feature?

I think that once programs/libraries get large enough hierarchical
package structure makes it easier conceptually to understand and
visualize connection between them. Then again I don't have much
experience writing large libraries, but rather using them.

dave

[Russ Cox]

On Wed, Mar 31, 2010 at 12:41, Dave B. <dave...@gmail.com> wrote:
> Is it possible to nest packages, Similar to c++ namespace feature?

Each package is in its own name space automatically,
without needing explicit annotations or management like
in C++. And import paths, which are the global identifiers
for packages, nest easily, since directories nest.

Otherwise I'm not entirely sure what you mean.

Russ

[Kevin Ballard]

I think he's suggesting having a package be used like
io.ioutil.ReadFile() (in this case it would probably be renamed to
io.util.ReadFile()). I'm not sure what the benefit would be though.

-Kevin Ballard

--
Kevin Ballard
http://kevin.sb.org
kbal...@gmail.com

[Steven]

> --
> To unsubscribe, reply using "remove me" as the subject.
>

No, you can't nest packages, but you can put a package in a
subdirectory, meaning you can group packages that way. You can look at
http://golang.org/pkg/
for examples, and in the src pkg directory in your goroot to see how it's done.

[Dave B.]

Yes, that's what I meant.

The benefit would be, IMO, to group programs/libraries into logical
domains and sub-domains. Also, in libraries/programs composed of many
other libraries, having a root package/namespace for each library
being used (e.g. std, numeric, OGRE) will make understanding the
overall structure of the program much easier.

On Apr 1, 12:11 am, Kevin Ballard <kball...@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 2:09 PM, Russ Cox <r...@golang.org> wrote:

> > On Wed, Mar 31, 2010 at 12:41, Dave B. <dave....@gmail.com> wrote:
> >> Is it possible to nest packages, Similar to c++ namespace feature?
>
> > Each package is in its own name space automatically,
> > without needing explicit annotations or management like
> > in C++.  And import paths, which are the global identifiers
> > for packages, nest easily, since directories nest.
>
> > Otherwise I'm not entirely sure what you mean.
>
> I think he's suggesting having a package be used like
> io.ioutil.ReadFile() (in this case it would probably be renamed to
> io.util.ReadFile()). I'm not sure what the benefit would be though.
>
> -Kevin Ballard
>
> --
> Kevin Ballardhttp://kevin.sb.org

> kball...@gmail.com

[Alexander Surma]

Why introduce some kind of hierachy into the package layout,
where the developers have purposely decided to use (almost) no hierarchies
in Go at all..
And the benefits - if any - are minimal. In the import you see the
belongings of a package
(if properly arranged into directories), and shouldn't need to be reminded
of those relations throughout the program. The names of those packages
are mostly selfexplainatory anyways.

my 2¢,
Surma

[David Roundy]

I think the answer lies in

import "io/ioutil"

It would be a cleaner import (less stuttering) if it were

import "io/util"

but then your uses of the package wouldn't mention io at all, and you
could be confused (until you checked the import statement).

I don't think it's an important thing to change, but that particular
package name suggests to me that something could be improved
somewhere. I don't know that adding in an extra dot is a big
improvement, but if it doesn't cause problems in the parser, it might
be worth allowing "." in package names.
--
David Roundy

[Stephen Weinberg]

I love the idea. I have always loved typing System.out.print() every
time I wanted to write something to the screen in AP Computer Science
class.

-- Stephen

[Dave B.]

I can't tell if you're cynical or not. I agree though that it gets
tiring the hundredth time you have to type
System.Console.WriteLine("blabla") and such. That's what using
statements are for... But I guess the Go creators didn't want to get
into all that.

The question remains, how did they envision managing large programs
structure with their current model?

Dave

[chris dollin]

On 1 April 2010 11:57, Dave B. <dave...@gmail.com> wrote:

I can't tell if you're cynical or not. I agree though that it gets
tiring the hundredth time you have to type
System.Console.WriteLine("blabla") and such. That's what using
statements are for... But I guess the Go creators didn't want to get
into all that.

The question remains, how did they envision managing large programs
structure with their current model?

You can put a package into a sub-directory. You can put dots and
hyphens and stuff in a directory name. So you can eg say

  import "www.electric-hedghog.net_code.go.packages/spoo"
 
and put all the "hierarchy" information into the long.directory.name.

It's not perfect, but then, what is?

Chris

--
Chris "allusive" Dollin

[Alexis Shaw]

and you can chane the name that it is imported as. via the second option!!

ie.

import "very/long/package.name" short

short.func()

[chris dollin]

On 1 April 2010 12:23, Alexis Shaw <alexi...@gmail.com> wrote:

and you can chane the name that it is imported as. via the second option!!

ie.

import "very/long/package.name" short

short.func()

Other way round, but yes.

--
Chris "allusive" Dollin

[Ian Lance Taylor]

"Dave B." <dave...@gmail.com> writes:

> The question remains, how did they envision managing large programs
> structure with their current model?

You can only refer to the names that you import, and you can choose
the name under which you import them. So there is no namespace
problem in any single file. Different packages can be put into
subdirectories, so there is no problem giving different filenames to
different packages. Nobody has written any truly large Go programs
yes, but I don't see any particular difficulty in managing them when
they come to pass.

Ian