On Fri, 27 Jun 2014 07:21:26 BST roger peppe wrote:
On 26 June 2014 18:18, Vlad Didenko wrote:
Is it an OK design when `internal` directory will be repeated multiple time s
in paths of complex projects? I kinda like flatter arrangements.
Looks like I made this question too subtle a dozen posts ago...
I actually asked this question earlier in this thread; Robert Griesemer
: I believe this would already be supported by the proposal.
: This is what would make it scalable. Basically, a large component can
: contain inner components.
[Reading the above triggered the following thought. I hope it
is helpful to some....]
In circuit design, a circuit consists of a set of connected
components. Some of these components are "atomic", with their
internal structure not visible; they just have a set of ports
for external connections. Some components may be modules with
an internal circuit connecting subcomponents & a subset of
ports exposed for external connections.
When using such a module in a bigger design, you can't
directly connect to an internal component; you can only
connect to the external ports.
The go package situation is somewhat analogous. Here, a file
is like a module that contains only "atomic" components.
Object defined in it & with captialized names are like
external ports. Import statements in effect specify potential
connections to other modules. A directory is like a module
that contains submodules. And the purpose is exactly
analogous; rather than define a single giant design, you break
it up in a set of smaller modules for reuse, ease of
debugging, ease of comprehension etc. etc.
But unlike in circuit design, go has no facility to define
"super modules" (modules containing submodules), where
internal modules are protected from outside (mis)use. In go
you can import an internal module even when that can cause
problems. There is no equivalent of the Capitalized name
trick at the directory level.
This is what the "internal" path component is supposed to fix.
Another option may have been to use a `public' file. That is,
if you have */foo/public, all other files below foo/ can't
be imported from *outside* the foo/ path. But this would
require constantly checking for */public files at every level
and anyway it is as arbitrary a choice as use of internal/.
In fact, using the "internal" path component makes things more
clear and efficient. That is, rather than have
foo/public foo/pkg1 foo/pkg2 ...
and only allow importing foo/public, you instead have
foo/public foo/internal/pkg1 foo/internal/pkg2
and disallow foo/internal/* from outside foo. And once you
decide to use the internal/ trick, it doesn't matter what you
call files at the foo/ level. Plus you can have more than one
such publically visible file at that level.
Since */internal/ defines the internal structure of a package,
the internal structure can certainly contain packages with
their own internal structures. Example: given packages
It is clear to see that
a can refer to b & f but not anyone else
b can refer to everyone but e
c can refer to everyone but e
d can refer to everyone else
e can refer to everyone else
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.