4 ms·

> Visibility (public/private) is done via the capitalization of the field, method, or type name. This sort of restriction doesn't hinder usability, but it's qui

> Visibility (public/private) is done via the capitalization of the field, method, or type name. This sort of restriction doesn't hinder usability, but it's quite annoying. While the capitalization of identifiers may be surprising, in practice it is one of the best features of go in my experience because no additional context is needed to know whether an identifier is exported. In rust, as far as I can tell, it is not possible without referring to the declaration. As far as globally changing whether an identifier is exported, it is easy with the gorename tool, no search and replace necessary. Gorename also updates any references to the identifier in other packages in $GOPATH. https://godoc.org/golang.org/x/tools/cmd/gorename https://godoc.org/golang.org/x/tools/cmd/gorename

solipsism 11y ago
no additional context is needed to know whether an identifier is exported Isn't this the same as the argument for Hungarian Notation? And isn't it a bit of a slippery slope? Why not add an 'i' for integers, so that no additional context is needed to know whether a variable is an integer. Etc. There is a lot of information about a particular identifier that it would be nice to know at any given time, and in my opinion it's arbitrary to pick just one and make it a language rule. A much better solution is for to use IDEs or text editor plugins to visually show (using color, formatting, bits of UI) that information in a user-configurable and context-dependent way.
- nordsieck 11y ago
  It's not the same. In Hungarian Notation, the type is enforced by a declaration, but it's documented by the prefix. In go, the enforcement and documentation are one and the same.
- aidos 11y ago
  In defence of hungarian notation, the way Joel tells it makes a lot of sense [0]: "Simonyi’s original concept for Hungarian notation was called, inside Microsoft, Apps Hungarian, because it was used in the Applications Division, to wit, Word and Excel. In Excel’s source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they’re both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means “horizontal coordinates relative to the layout” and xw means “horizontal coordinates relative to the window.” Both ints. Not interchangeable. In both apps you see a lot of cb meaning “count of bytes.” Yep, it’s an int again, but you know so much more about it just by looking at the variable name. It’s a count of bytes: a buffer size. And if you see xl = cb, well, blow the Bad Code Whistle, that is obviously wrong code, because even though xl and cb are both integers, it’s completely crazy to set a horizontal offset in pixels to a count of bytes." It's actually a practice I now use myself in certain contexts. [0] http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
  - TheLoneWolfling 11y ago
    This is one of the cases where I like languages that allow extendable types. Being able to declare that a variable is in radians, for example. (Bonus points if it can auto-convert.)
    - NateDad 11y ago
      Go can do this easily: type Radians float type Degrees float func (r Radians) ToDegrees() Degrees { // maths here }
      - sukilot 11y ago
        That's not auto convert. Scala implicit is auto convert.
        NateDad 11y ago
        Auto converting is an anti pattern. Explicit is better than implicit. Auto conversion is how mistakes get made. This is why modern languages don't let you implicitly convert from a string to an int, for example.
      - TheLoneWolfling 11y ago
        That's not what I mean by autoconverting. I meant as in quite literally being able to use something of type Radians in something that expects Degrees and it "just works", and vice versa. I dislike Go's overuse of "explicit being better than implicit", and this is no exception. It's supposedly to prevent bugs, but it adds so much more verbosity that half the time you're adding more bugs by the additional verbosity than you're fixing via the reduction of magic.
    - strictfp 11y ago
      Sounds interresting! Could you provide a link? Can't seem to find anything relevant.
      - 11y ago
- skriticos2 11y ago
  The Hungarian notation is informal and not enforced by compilers. You can easily do >> bool iMyInt; It's obviously wrong, but the compiler will happily compile it. When you declare the following in go: >> type NotExported struct {} You still know it's exported, no matter what BS the programmer writes.
phloxicon 11y ago
I really like the idea of capitalization selecting public and private scope. However, how do they use protected scope?
- IshKebab 11y ago
  There is no protected. There's no inheritance anyway.
  - NateDad 11y ago
    Note that everything in the same package can access all the private stuff... so you do have some flexibility. You can write two types that reference each other's private data/functionality... they just need to be in the same package.

solipsism 11y ago

no additional context is needed to know whether an identifier is exported Isn't this the same as the argument for Hungarian Notation? And isn't it a bit of a slippery slope? Why not add an 'i' for integers, so that no additional context is needed to know whether a variable is an integer. Etc. There is a lot of information about a particular identifier that it would be nice to know at any given time, and in my opinion it's arbitrary to pick just one and make it a language rule. A much better solution is for to use IDEs or text editor plugins to visually show (using color, formatting, bits of UI) that information in a user-configurable and context-dependent way.

nordsieck 11y ago
It's not the same. In Hungarian Notation, the type is enforced by a declaration, but it's documented by the prefix. In go, the enforcement and documentation are one and the same.
aidos 11y ago
In defence of hungarian notation, the way Joel tells it makes a lot of sense [0]: "Simonyi’s original concept for Hungarian notation was called, inside Microsoft, Apps Hungarian, because it was used in the Applications Division, to wit, Word and Excel. In Excel’s source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they’re both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means “horizontal coordinates relative to the layout” and xw means “horizontal coordinates relative to the window.” Both ints. Not interchangeable. In both apps you see a lot of cb meaning “count of bytes.” Yep, it’s an int again, but you know so much more about it just by looking at the variable name. It’s a count of bytes: a buffer size. And if you see xl = cb, well, blow the Bad Code Whistle, that is obviously wrong code, because even though xl and cb are both integers, it’s completely crazy to set a horizontal offset in pixels to a count of bytes." It's actually a practice I now use myself in certain contexts. [0] http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
- TheLoneWolfling 11y ago
  This is one of the cases where I like languages that allow extendable types. Being able to declare that a variable is in radians, for example. (Bonus points if it can auto-convert.)
  - NateDad 11y ago
    Go can do this easily: type Radians float type Degrees float func (r Radians) ToDegrees() Degrees { // maths here }
    - sukilot 11y ago
      That's not auto convert. Scala implicit is auto convert.
      - NateDad 11y ago
        Auto converting is an anti pattern. Explicit is better than implicit. Auto conversion is how mistakes get made. This is why modern languages don't let you implicitly convert from a string to an int, for example.
    - TheLoneWolfling 11y ago
      That's not what I mean by autoconverting. I meant as in quite literally being able to use something of type Radians in something that expects Degrees and it "just works", and vice versa. I dislike Go's overuse of "explicit being better than implicit", and this is no exception. It's supposedly to prevent bugs, but it adds so much more verbosity that half the time you're adding more bugs by the additional verbosity than you're fixing via the reduction of magic.
  - strictfp 11y ago
    Sounds interresting! Could you provide a link? Can't seem to find anything relevant.
    - 11y ago
skriticos2 11y ago
The Hungarian notation is informal and not enforced by compilers. You can easily do >> bool iMyInt; It's obviously wrong, but the compiler will happily compile it. When you declare the following in go: >> type NotExported struct {} You still know it's exported, no matter what BS the programmer writes.

phloxicon 11y ago

I really like the idea of capitalization selecting public and private scope. However, how do they use protected scope?

IshKebab 11y ago
There is no protected. There's no inheritance anyway.
- NateDad 11y ago
  Note that everything in the same package can access all the private stuff... so you do have some flexibility. You can write two types that reference each other's private data/functionality... they just need to be in the same package.