Shadowed Identifiers
Peter Froehlich
I didn't want to start an issue for this before bringing it up here.
The basic request would be for Go compilers to generate a warning
whenever an identifier is shadowed. The rest of this is
background/motivation. See Issue 377 for a slightly different
motivation.
I ran into this recently while working a little on Michael Hoisie's
web.go framework [1]. The "problem" is that many modules from the
standard library have very common names, for example "path". Using
"path" as a parameter or local is pretty natural, especially in a web
framework. If you have the "path" module imported as well, you'll be
due for a number of renamings as soon as you want to actually call a
function in "path" if you're also using it as a local variable. To a
smaller degree this also happens for len a lot, which is a natural
name for people to pick when they have some length to deal with.
Of course the fixes for this are easy without a compiler change. But
personally I'd rather have the compiler bicker the first time I use an
identifier that I could later regret using.
For imports the easiest fix is to always give them a name explicitly,
preferably a capitalized name. There's already an example in the
language spec: import M "math" instead of just import "math". Since
those identifiers can be capitalized without being "exported" you can
avoid most problems that way (unless you also use import . "something"
and you have a clash there, but dotted import is insane anyway). Also
it seems works well with my Oberon background since capitalized module
names was sort of the default there.
If nothing else happens, I'd like to at least suggest a paragraph
about this for "Effective Go" (yes I volunteer for writing it).
Cheers,
Peter
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab
Peter Froehlich
[1] http://github.com/hoisie/web.go
[2] http://github.com/phf/web.go
Peter Froehlich
with capitalized module aliases.
http://github.com/phf/web.go/tree/module-names
SnakE
I made a branch of web.go to show everybody what it would look like
with capitalized module aliases.
http://github.com/phf/web.go/tree/module-names
I don't like your particular example. Package names are short enough in Go already. Making them even shorter makes the code unreadable for anyone unfamiliar with your convention for this particular module.
The convention of capitalizing package names may work though. If the package was defined "package FMT" in fmt.go you'd get it automatically when importing, no need for rename.
Anyway I'd prefer to keep number of caps in my code at a minimum.
Peter Froehlich
> I don't like your particular example. Package names are short enough in Go
> already. Making them even shorter makes the code unreadable for anyone
> unfamiliar with your convention for this particular module.
This is a familiar argument, there were disagreements about this for
Oberon as well years ago. If I recall correctly the conclusion was
that since the names are local to a module (as you say), they are easy
to find and resolve. But yes, that is a drawback. minor in my opinion.
Capitalized names are convenient for this since they can't really be
anything else in Go (once again unless you use the dreaded dotted
import). I am not a caps addict either, it's just pragmatic.
Russ Cox
warn about shadowed names. That is issue 377,
as you noted. I don't think there's much to add here:
it was deliberate that variable names can be shadowed,
and there are consequences. On the other hand, it works
well in many cases too.
I can't tell exactly what you are proposing with respect
to package naming convention. It sounds like you want
to disallow unnamed imports, so that one must always
write
import (
Fmt "fmt"
Math "math"
Os "os"
Sort "sort"
)
One of the explicit goals in many of Go's syntactic
decisions is to reduce the amount of typing by
avoiding needless repetition of information.
This certainly counts.
As far as upper vs lower case, that convention is
already established and seems to be working well
(among other things it avoids deciding whether
the capitalization of "os" is OS or Os).
The fact that it's different from Oberon doesn't bother us.
You claimed that name clashes are a common problem,
but in the Go tree the only one package ever gets renamed:
"path", 5 times out of 12. The solution there is easy:
import pathutil "path"
If it ends up being a persistent problem a simpler
solution would be to rename the path package itself.
Russ
Peter Froehlich
> I can't tell exactly what you are proposing with respect
> to package naming convention. It sounds like you want
> to disallow unnamed imports, so that one must always
> write
I never asked for a language change, just a compiler warning. I simply
provided a different motivation for Issue 377.
> The fact that it's different from Oberon doesn't bother us.
I am sure it doesn't. :-D
Devon H. O'Dell
> On Wed, Dec 23, 2009 at 3:23 PM, Russ Cox <r...@golang.org> wrote:
>> I can't tell exactly what you are proposing with respect
>> to package naming convention. It sounds like you want
>> to disallow unnamed imports, so that one must always
>> write
>
> I never asked for a language change, just a compiler warning. I simply
> provided a different motivation for Issue 377.
I believe the current convention is that the compiler doesn't warn, only errors.
--dho
Peter Froehlich
I had a feeling that's the case, but I wasn't sure where that feeling
came from anymore. Maybe it's on the Go site somewhere. In any case,
it's not like we lack the tools to write golint. Anyone volunteering?
Devon H. O'Dell
> On Wed, Dec 23, 2009 at 3:47 PM, Devon H. O'Dell <devon...@gmail.com> wrote:
>> 2009/12/23 Peter Froehlich <peter.hans...@gmail.com>:
>>> On Wed, Dec 23, 2009 at 3:23 PM, Russ Cox <r...@golang.org> wrote:
>>>> I can't tell exactly what you are proposing with respect
>>>> to package naming convention. It sounds like you want
>>>> to disallow unnamed imports, so that one must always
>>>> write
>>>
>>> I never asked for a language change, just a compiler warning. I simply
>>> provided a different motivation for Issue 377.
>>
>> I believe the current convention is that the compiler doesn't warn, only errors.
>
> I had a feeling that's the case, but I wasn't sure where that feeling
> came from anymore. Maybe it's on the Go site somewhere. In any case,
> it's not like we lack the tools to write golint. Anyone volunteering?
Not sure. The closest thing to that is gofmt, and if we're supposed to
allow shadowing, it doesn't make that much sense to have gofmt remove
it. Not a straightforward problem to solve.
--dho
--dho
