FAQ
I would like to share some idea from NPM.
The package system for node.js use a folder named `node_modules` as a short
cut to local package.
Maybe plus the UNIX philosophy, could use a hidden folder name `.internal`
at the start of share point instead of add path trick for package import


Cheers,

Terry Huang
rsc於 2014年6月19日星期四UTC+8上午3時42分48秒寫道:
golang.org/s/go14internal
comments welcome on this mail thread. thanks.
--
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 golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Vlad Didenko at Jun 26, 2014 at 5:18 pm
    Is it an OK design when `internal` directory will be repeated multiple
    times in paths of complex projects? I kinda like flatter arrangements.

    Looks like I made this question too subtle a dozen posts ago...
    On Monday, June 23, 2014 10:51:06 PM UTC-5, Vlad Didenko wrote:

    Russ,

    Thank you for chiming in at my google+ post
    <https://plus.google.com/u/0/+VladDidenko/posts/UJd77yxVS3D> and
    discussion about the `internal`. It is unfortunate I was not aware this is
    the "canonical" place for the discussion.

    I understand that my suggestion is off the table based on your comment.
    The reason I started to think about it, though, is that I was trying in my
    mind to avoid paths like

    /github.com/user/project/internal/subproject/internal/leaf

    and instead use

    /github.com/user/Project/subproject/leaf

    The thought being that Go community will go far to have a uniform "Capitalized
    Gets Exported" principle.

    Regardless, did someone consider usability of multiple "internal"
    designators? Also, did you consider the form:

    /github.com/user/project/-/subproject/-/leaf

    similar to meta keule suggestion, but with the not-so-special character?

    Vlad
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Jun 26, 2014 at 5:42 pm

    On Thu, Jun 26, 2014 at 1:18 PM, Vlad Didenko wrote:

    Is it an OK design when `internal` directory will be repeated multiple
    times in paths of complex projects? I kinda like flatter arrangements.
    I don't expect internal to be repeated in any import path in our usage.
    Other people might overuse it, but people can overuse anything.

    Russ

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rob Pike at Jun 26, 2014 at 5:52 pm
    Anything important enough to be in a dot-file is important enough not
    to be in a dot-file.

    -rob

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger peppe at Jun 27, 2014 at 6:21 am

    On 26 June 2014 18:18, Vlad Didenko wrote:
    Is it an OK design when `internal` directory will be repeated multiple times
    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
    replied, saying:

    : 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.

    I hope that's still the plan. Our project would benefit from it, I think,
    and Gustavo's point about third-party packages is a good one too.

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bakul Shah at Jun 27, 2014 at 7:52 am

    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
    replied, saying:

    : 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

      a
      foo/b
      foo/internal/c
      foo/internal/bar/d
      foo/internal/bar/internal/e
      foo/f

    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger peppe at Jun 27, 2014 at 8:07 am

    On 27 June 2014 08:52, Bakul Shah wrote:
    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
    replied, saying:

    : 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.
    I agree that this should be the case.

    The proposal as it currently stands doesn't explicitly address
    this case though, which is why I suggested a minor
    modification to the rules earlier.
    Example: given packages

    a
    foo/b
    foo/internal/c
    foo/internal/bar/d
    foo/internal/bar/internal/e
    foo/f

    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
    Yes.

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at Jun 26, 2014 at 5:19 pm

    Maybe plus the UNIX philosophy, could use a hidden folder name `.internal`
    at the start of share point instead of add path trick for package import
    There's nothing Unix about .hidden crap:
    https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp, except
    perhaps if by UNIX you mean that cancer that grew around Unix.

    --
    Aram Hăvărneanu

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thomas Wilde at Jun 26, 2014 at 7:55 pm
    Coming to think of it, comparing the use case to namespaces and so called
    "inner" classes in other languages and considering the fact that the empty
    string is not a valid package name; maybe do the exact opposite of what I
    just implicitly proposed. Namely that package "a/b/c" had access to
    unexported members of "a/b" and "a", yet not to "a/b/d" or "b", for that
    matter.

    And if this way around the idea turned out to be even worse; *we have
    (presumably) both failed to consider the fact that it is only by convention
    that the go tool maps import paths to directories*, giving special meaning
    to the slash character. This is not part of the language specification. The
    import path should be able to be any string.

    This specificity is what I believe goes against Go's fundament; namely the
    introduction of a special sequence of characters inside an arbitrary string
    that will affect the current package's symbol table. Don't get me wrong,
    this is not a critique -- just my personal opinion which I believe to be in
    concordance with Go's fundamental philosophy. But I could be wrong.


    On Thu, Jun 26, 2014 at 3:48 PM, Russ Cox wrote:
    On Wed, Jun 25, 2014 at 4:49 AM, tomwilde wrote:

    a little over 2 years ago when I was learning Go, it seamed intuitive to
    me that package "a/b" could access unexported members of package "a/b/.+"
    and I was surprised to learn that this was not the case.

    I even opened a question about it on stack overflow.
    <http://stackoverflow.com/questions/9298676/visibility-in-sub-packages>

    Therefore, I support your motion with 1 nitpick; drop the "internal"
    specifier.
    That doesn't actually solve the problem we are trying to solve. The
    internal keyword is important because it gives an explicit marker for where
    the scope begins: a/b/c/d/e can import a/b/internal/x/y/z, but a/b/c/d/e is
    not a parent of a/b/x/y/z. More concretely, cmd/nm and cmd/objdump should
    share some code. Where can it go? In your proposal either a subdirectory of
    cmd/nm (which objdump can't use) or a subdirectory of cmd/objdump (which nm
    can't use). But cmd/internal would work fine.

    Russ
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Jun 26, 2014 at 8:40 pm

    On Thu, Jun 26, 2014 at 3:55 PM, Thomas Wilde wrote:

    Coming to think of it, comparing the use case to namespaces and so called
    "inner" classes in other languages and considering the fact that the empty
    string is not a valid package name; maybe do the exact opposite of what I
    just implicitly proposed. Namely that package "a/b/c" had access to
    unexported members of "a/b" and "a", yet not to "a/b/d" or "b", for that
    matter.
    To everyone proposing solutions: Before you post, please read the three
    scenarios on the first page of golang.org/s/go14internal and make sure your
    proposal handles them.

    This one doesn't work either: where does the code shared between
    cmd/objdump and cmd/nm live?

    And you are still confusing the language and the tools. The language leaves
    import paths as opaque strings; the go command interprets them in a
    particular way and is what is implementing this visibility rule.

    And if this way around the idea turned out to be even worse; *we have
    (presumably) both failed to consider the fact that it is only by convention
    that the go tool maps import paths to directories*, giving special
    meaning to the slash character. This is not part of the language
    specification. The import path should be able to be any string.
    >
    This specificity is what I believe goes against Go's fundament; namely the
    introduction of a special sequence of characters inside an arbitrary string
    that will affect the current package's symbol table.
    I don't think you understand the proposal. All the facts in the first
    paragraph are true except the one claiming that I didn't consider them. But
    the second paragraph is completely wrong. The presence of /internal/ in the
    import path affects whether the go command - which is already applying an
    interpretation of import paths - chooses to compile the program. If there
    is a disallowed import, it will not. All the rules about symbol visibility
    still apply. In particular, we are not changing which symbols are exported
    from the package, which symbols are visible to other packages.

    The new rule disallows certain import statements. That is all.

    Russ

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thomas Wilde at Jun 27, 2014 at 8:37 am

    The go tool has put semantics into import paths from day one. That is the
    point of the tool!
    Sorry if I was unclear; I meant language semantics, that is, visibility
    rules are language semantics territory.

    The only other case AFAIK in which you write code for the toolchain and not
    the program is build tags and those are comments from a language point of
    view.

    From that base you would still be right that import paths as well as
    comments are just arbitrary character sequences and hence no semantic or
    structure is implied upon their content from the language alone. But I
    could then argue that we should derive the restriction from e.g.
    backticked-strings; if the file contains a backticked string containing the
    wording `foobar` at the top level then it's "internal" à la perl or
    javascript "use strict", "use warnings" (or whatever).

    Do you see where I'm going? the choice of the import path and the character
    sequence "internal" is just very arbitrary and has an effect on the program
    i.e. it will not compile if I write one sequence of characters but it will
    with another (Same would happen if I typed a non-existing import path but
    in that case it's not the tool imposing restrictions on me -- the file
    simply doesn't exist).
    An import declaration [...] enables access to exported identifiers of
    [the imported] package.

    This rule in the language spec would be conditional now, as well.

    In general and from a logical point of view you can probably get away with
    the "internal" idea; my point is that it doesn't seem a Go-y thing to do.

    - Tom

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jesse McNelis at Jun 27, 2014 at 3:10 pm

    On Fri, Jun 27, 2014 at 6:37 PM, Thomas Wilde wrote:
    Do you see where I'm going? the choice of the import path and the character
    sequence "internal" is just very arbitrary and has an effect on the program
    i.e. it will not compile if I write one sequence of characters but it will
    with another (Same would happen if I typed a non-existing import path but in
    that case it's not the tool imposing restrictions on me -- the file simply
    doesn't exist).
    Since import strings are arbitrary strings they can refer to files or
    urls or named pipes or GPS coordinates for a box filled with
    handwritten code on paper and this is all dependant on how the build
    tool wants to interpret the string. The existence of any import string
    referring to a valid package is always a restriction imposed by the
    build tool.

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tomwilde at Jun 27, 2014 at 4:42 pm
    or GPS coordinates for a box filled with handwritten code on paper
    Either the box exists and the tool consumes its content or the box is not
    there and that's an error.

    Refusing to consume the content of the box because the GPS coordinate
    contained the sequence 666 is superstition.

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Jun 27, 2014 at 4:51 pm

    On Fri, Jun 27, 2014 at 12:42 PM, tomwilde wrote:

    or GPS coordinates for a box filled with handwritten code on paper
    Either the box exists and the tool consumes its content or the box is not
    there and that's an error.

    Refusing to consume the content of the box because the GPS coordinate
    contained the sequence 666 is superstition.
    You've made your point. I am sorry if you don't believe the proposal is "a
    Go-y thing to do", but we will have to agree to disagree.

    Russ

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Anupam Kapoor at Jun 27, 2014 at 5:18 am
    [Thu, 26 Jun 2014 09:45:08 -0400]: "Russ Cox" (russ-cox):
      russ-cox> On Wed, Jun 25, 2014 at 6:38 AM, Anupam Kapoor
      russ-cox> wrote:

      ,----[ anupam-kapoor ]
    hmm, ok, basically, what i was trying to say was that, making
    file-system a part of the language to facilitate
    programming-at-large
    rather than relying on keywords makes things more contrived.

    but give the plan9 heritage, it is probably very easy to do...
    `----
    ,----[ russ-cox ]
    You are confusing what symbols are visible given an import (that uses
    upper vs lower case, which replaced an 'export' keyword) with what
    imports are allowed.

    You are also confusing the language and the go command. The language
    says nothing about how to interpret import paths. The go command
    defines that (for people building programs using it), and the
    definition already made use of a specific directory layout. This
    proposal adjusts the go command's definition only.
    `----
    i _was_ under the impression that import paths are more or less an
    opaque kind of token. however, thinking some more about it, the 'go
    tool' has put semantics into import paths since from the very
    begining.

    hopefully, as long as the number of micro-tweaks required for package
    dependancy management is minimal, folks don't have to touch source files
    all over the place often.

    thanks
    anupam

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJun 26, '14 at 4:24p
activeJun 27, '14 at 4:51p
posts15
users10
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase