code review 5696083: cmd/go: explain x... vs. x/... in help importpath

cmd/go: explain x... vs. x/... in help importpath
Fixes issue 3110.

[r, 2012-02-26 20:34:43]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/

[bradfitz, 2012-02-26 22:48:14]

LGTM

On Sun, Feb 26, 2012 at 12:34 PM, <r@golang.org> wrote:

> Reviewers: golang-dev_googlegroups.com,
>
> Message:
> Hello golang-dev@googlegroups.com,
>
> I'd like you to review this change to
> https://code.google.com/p/go/
>
>
> Description:
> cmd/go: explain x... vs. x/... in help importpath
> Fixes issue 3110.
>
> Please review this at
http://codereview.appspot.com/**5696083/<http://codereview.appspot.com/5696083/>
>
> Affected files:
>  M src/cmd/go/help.go
>
>
> Index: src/cmd/go/help.go
> ==============================**==============================**=======
> --- a/src/cmd/go/help.go
> +++ b/src/cmd/go/help.go
> @@ -34,8 +34,9 @@
>  each of which can match any string, including the empty string and
>  strings containing slashes.  Such a pattern expands to all package
>  directories found in the GOPATH trees with names matching the
> -patterns.  For example, encoding/... expands to all packages
> -in the encoding tree.
> +patterns.  For example, encoding/... expands to all package
> +in subdirectories of the encoding tree, while net... expands to
> +net and all its subdirectories.
>
>  An import path can also name a package to be downloaded from
>  a remote repository.  Run 'go help remote' for details.
>
>
>

[r, 2012-02-26 22:52:03]

*** Submitted as http://code.google.com/p/go/source/detail?r=9b92ebc5a9be ***

cmd/go: explain x... vs. x/... in help importpath
Fixes issue 3110.

R=golang-dev, bradfitz
CC=golang-dev
http://codereview.appspot.com/5696083

[rsc, 2012-02-28 16:00:33]

http://codereview.appspot.com/5696083/diff/1002/src/cmd/go/help.go
File src/cmd/go/help.go (right):

http://codereview.appspot.com/5696083/diff/1002/src/cmd/go/help.go#newcode38
src/cmd/go/help.go:38: in subdirectories of the encoding tree, while net...
expands to
No change needed, but an observation:
net... would also expands to netchan, since the wildcard is
purely lexical.  However, right now there are no instances
in the standard library where one package has a name that
is a prefix of another non-subdirectory package, so there 
is no way to expand this example to illustrate that.

[r2, 2012-02-28 20:45:36]

On 29/02/2012, at 3:00 AM, rsc@golang.org wrote:

> 
> http://codereview.appspot.com/5696083/diff/1002/src/cmd/go/help.go
> File src/cmd/go/help.go (right):
> 
> http://codereview.appspot.com/5696083/diff/1002/src/cmd/go/help.go#newcode38
> src/cmd/go/help.go:38: in subdirectories of the encoding tree, while
> net... expands to
> No change needed, but an observation:
> net... would also expands to netchan, since the wildcard is
> purely lexical.  However, right now there are no instances
> in the standard library where one package has a name that
> is a prefix of another non-subdirectory package, so there
> is no way to expand this example to illustrate that.

yes.

pattern matching is like that: sometimes it matches things you don't want. not
sure anything is called for, but i observe that people will continue to think
that net/* gives net as well. i believe that they're not thinking right, but
we'll see this "issue" again, and i wanted to get something into the docs to
suggest why.

one could argue that net... could be interpreted not to match netchan, but net/*
and net/..., but i won't make that argument because i don't want to document
that behavior.

-rob