3 ms·

I don't get how "great" it is to let capitalization be used for exported identifiers. What is the rationale behind this?

by junke 10y ago

ngrilly 10y ago
According to Rob Pike: "This was not an easy design decision. We spent over a year struggling to define the notation to specify an identifier's visibility. Once we settled on using the case of the name, we soon realized it had become one of the most important properties about the language. The name is, after all, what clients of the package use; putting the visibility in the name rather than its type means that it's always clear when looking at an identifier whether it is part of the public API. After using Go for a while, it feels burdensome when going back to other languages that require looking up the declaration to discover this information." Source: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article Must be noted that any identifier that doesn't start with an uppercase letter is not exported. This makes possible to use an underscore to mark unexported identifier and still use uppercase letters (like _Name or _SOME_CONSTANT), which is a common practice in many programming languages (like Python). This is not idiomatic in Go, but it's possible.
- ngrilly 10y ago
  Why the downvote?
  - tkxxx7 10y ago
    I didn't downvote, but I'd guess it's because you didn't answer the parent's question exactly, which was asking the OP's rationale for their opinion (not the rationale for the addition to the language). Your comment still provides valuable context so it seems unfair to me.
  - junke 10y ago
    I didn't downvote either. I would have like to read a more convincing answer, but this always come down to "Rob Pike says so". I found an old thread about this btw: https://news.ycombinator.com/item?id=5201461 https://news.ycombinator.com/item?id=5201461.
    - ngrilly 10y ago
      It's not because "Rob Pike says so". It just happens that I agree with him on this matter, which is why I mentioned his answer :-) Thanks for the link, including tptacek comments, which are very convincing.
      - junke 10y ago
        > As a result, a lot of packages do The Simplest Thing That Could Possibly Work and just expose simple functions. The result is usually refreshingly clear. That's what I do too, but I don't change names. I use "export" declarations for packages, which are completely orthogonal to what the symbol represents. Less naming problems. The capitalization thing would be in the "Meh" category for me, that's all.
        ngrilly 10y ago
        Interesting! In which language?
        junke 10y ago
        Common Lisp (packages and symbols are first class). There are some gotchas at first but then they feel quite natural. You write your code in one place and manage visibility elsewhere. This allows for example to make a symbol exported in different packages, or take separate code and provide a unified facade package. But most of the time you just need to define the public interface of your code and this is quite easy.

I don't get how "great" it is to let capitalization be used for exported identifiers. What is the rationale behind this?

by junke 10y ago

I don't get how "great" it is to let capitalization be used for exported identifiers. What is the rationale behind this?

ngrilly 10y ago

According to Rob Pike: "This was not an easy design decision. We spent over a year struggling to define the notation to specify an identifier's visibility. Once we settled on using the case of the name, we soon realized it had become one of the most important properties about the language. The name is, after all, what clients of the package use; putting the visibility in the name rather than its type means that it's always clear when looking at an identifier whether it is part of the public API. After using Go for a while, it feels burdensome when going back to other languages that require looking up the declaration to discover this information." Source: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article Must be noted that any identifier that doesn't start with an uppercase letter is not exported. This makes possible to use an underscore to mark unexported identifier and still use uppercase letters (like _Name or _SOME_CONSTANT), which is a common practice in many programming languages (like Python). This is not idiomatic in Go, but it's possible.

ngrilly 10y ago
Why the downvote?
- tkxxx7 10y ago
  I didn't downvote, but I'd guess it's because you didn't answer the parent's question exactly, which was asking the OP's rationale for their opinion (not the rationale for the addition to the language). Your comment still provides valuable context so it seems unfair to me.
- junke 10y ago
  I didn't downvote either. I would have like to read a more convincing answer, but this always come down to "Rob Pike says so". I found an old thread about this btw: https://news.ycombinator.com/item?id=5201461 https://news.ycombinator.com/item?id=5201461.
  - ngrilly 10y ago
    It's not because "Rob Pike says so". It just happens that I agree with him on this matter, which is why I mentioned his answer :-) Thanks for the link, including tptacek comments, which are very convincing.
    - junke 10y ago
      > As a result, a lot of packages do The Simplest Thing That Could Possibly Work and just expose simple functions. The result is usually refreshingly clear. That's what I do too, but I don't change names. I use "export" declarations for packages, which are completely orthogonal to what the symbol represents. Less naming problems. The capitalization thing would be in the "Meh" category for me, that's all.
      - ngrilly 10y ago
        Interesting! In which language?
        junke 10y ago
        Common Lisp (packages and symbols are first class). There are some gotchas at first but then they feel quite natural. You write your code in one place and manage visibility elsewhere. This allows for example to make a symbol exported in different packages, or take separate code and provide a unified facade package. But most of the time you just need to define the public interface of your code and this is quite easy.