3 ms·

The problem with capitalization for me comes when interfacing with external json. Suddenly serializable structs have to be exported (since introspection doesn't

The problem with capitalization for me comes when interfacing with external json. Suddenly serializable structs have to be exported (since introspection doesn't work on private structs) which means that none of the names match the json names anymore (the web world tends to use lowercase or camel case with the first word uncapitalized). So now every json structure had to not only be public but also has to have introspection hints (`json: "my_field_name"`). It makes everything verbose and ugly. In these cases I'd much rather have "pub" in front of some lowercase names that match the json I'm reading or writing.

infogulch 9y ago
I feel like changing the implementation of a core feature just to make json serialization a little easier would be the completely wrong thing to optimize for. 99% of go code is not json serialization structs. Are you going to name all your fields with underscores for the same reason? What if you're using the same struct with your database? Are you going all the way and name your database fields based on your json api naming conventions just so you don't have to write some metadata? I'll take writing tags, thanks.
- __david__ 9y ago
  You're missing the point a little, I think. It's not just JSON, it's anywhere your Go code interfaces with the outside world. That's where you start fighting with Go case conventions vs. the rest of the world. I like the concept of tags in principle, but in practice they end up being very repetitive. Compare it with Rust's "serde" stuff—it's much nicer.
  - infogulch 9y ago
    Boundary layers will always have naming convention conflicts. Even serde has `#[serde(rename = "name")]` [1] for this purpose. It's unlikely that go will ever be able to approach the powerful and general compile-time code generation/macros that rust avails awesome libraries like serde. I guess it's a difference of perspective: do you let the outside world's naming conventions leak into your codebase, or do you translate at the boundary? Go's field tags chooses to keep consistent naming internally and translate at the boundary, in exchange for defining that translation explicitly. Note, in some cases you will have conflicts no matter what you choose (e.g. serializing both json and database). The outside world is going to be messy and inconsistent and full of conflicts. I would prefer to keep that external to my codebase as much as possible and follow a consistent naming convention within the language instead of letting the outside world and its whims dictate it. [1]: https://serde.rs/field-attrs.html https://serde.rs/field-attrs.html
    - ayosec 9y ago
      > Even serde has `#[serde(rename = "name")]` for this purpose. You can use `#[serde(rename_all = "camelCase")]`[1] in the struct to apply the fix to all fields. [1]: https://serde.rs/container-attrs.html#serderenameall-- https://serde.rs/container-attrs.html#serderenameall--

infogulch 9y ago

I feel like changing the implementation of a core feature just to make json serialization a little easier would be the completely wrong thing to optimize for. 99% of go code is not json serialization structs. Are you going to name all your fields with underscores for the same reason? What if you're using the same struct with your database? Are you going all the way and name your database fields based on your json api naming conventions just so you don't have to write some metadata? I'll take writing tags, thanks.

__david__ 9y ago
You're missing the point a little, I think. It's not just JSON, it's anywhere your Go code interfaces with the outside world. That's where you start fighting with Go case conventions vs. the rest of the world. I like the concept of tags in principle, but in practice they end up being very repetitive. Compare it with Rust's "serde" stuff—it's much nicer.
- infogulch 9y ago
  Boundary layers will always have naming convention conflicts. Even serde has `#[serde(rename = "name")]` [1] for this purpose. It's unlikely that go will ever be able to approach the powerful and general compile-time code generation/macros that rust avails awesome libraries like serde. I guess it's a difference of perspective: do you let the outside world's naming conventions leak into your codebase, or do you translate at the boundary? Go's field tags chooses to keep consistent naming internally and translate at the boundary, in exchange for defining that translation explicitly. Note, in some cases you will have conflicts no matter what you choose (e.g. serializing both json and database). The outside world is going to be messy and inconsistent and full of conflicts. I would prefer to keep that external to my codebase as much as possible and follow a consistent naming convention within the language instead of letting the outside world and its whims dictate it. [1]: https://serde.rs/field-attrs.html https://serde.rs/field-attrs.html
  - ayosec 9y ago
    > Even serde has `#[serde(rename = "name")]` for this purpose. You can use `#[serde(rename_all = "camelCase")]`[1] in the struct to apply the fix to all fields. [1]: https://serde.rs/container-attrs.html#serderenameall-- https://serde.rs/container-attrs.html#serderenameall--