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

Search Discussions

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJun 26, '14 at 7:55p
activeJun 26, '14 at 8:40p
posts2
users2
websitegolang.org

2 users in discussion

Russ Cox: 1 post Thomas Wilde: 1 post

People

Translate

site design / logo © 2021 Grokbase