2 ms·

Especially given I just commented on another thread that I was surprised at a suggestion Go might “become the next PHP”, these are much more compelling complain

Especially given I just commented on another thread that I was surprised at a suggestion Go might “become the next PHP”, these are much more compelling complaints than what I usually encounter. I’m not a Go dev so I only have a fuzzy view into the actual dev experience. But I would never have imagined that you’re expected to make struct types public in order to return instances. That’s a baseline expectation of hiding implementation details right? Along with logging levels, I’m shocked that this is more painful than in typical JS/TS setups.

azurelake 5y ago
You can make the type itself public without making the fields public. This means someone could hypothetically create one of your structs without using the "New" function you provide, but it's not an issue in practice. And if you really want to avoid exporting your struct at all, you can always just return an interface.
- eyelidlessness 5y ago
  > And if you really want to avoid exporting your struct at all, you can always just return an interface. This is what I think most TypeScript libraries should be doing, but every bit of inertia makes it unlikely. In all honesty I think type systems should be designed around contracts/protocols and make concrete types private by default. Sure it’s a lot of ceremony, but it’s less ceremony than human communication in emails and issue threads to clarify that undocumented features are undocumented on purpose.
Beltalowda 5y ago
> I would never have imagined that you’re expected to make struct types public in order to return instances You can return unexported ("private") instances; for example this is perfectly valid: type unexport struct { Str string } func (unexport) Method() string { return "export" } func NewUnexport() unexport { return unexport{Str: "asd"} } And you can get/set the exported Str field from another package without problems, as well as call the exported Method. You don't even need to make an unexport package type and can use an anonymous struct or type declared in the function too, although you can't add any methods like this and is often cumbersome because you need to declare the anonymous struct more than one. And, of course, you can make parts of a struct private by just not exporting them. It's really not all that different to how OOP languages work with public/private, except that visibility is dictated in the name itself.

azurelake 5y ago

You can make the type itself public without making the fields public. This means someone could hypothetically create one of your structs without using the "New" function you provide, but it's not an issue in practice. And if you really want to avoid exporting your struct at all, you can always just return an interface.

eyelidlessness 5y ago
> And if you really want to avoid exporting your struct at all, you can always just return an interface. This is what I think most TypeScript libraries should be doing, but every bit of inertia makes it unlikely. In all honesty I think type systems should be designed around contracts/protocols and make concrete types private by default. Sure it’s a lot of ceremony, but it’s less ceremony than human communication in emails and issue threads to clarify that undocumented features are undocumented on purpose.

Beltalowda 5y ago

> I would never have imagined that you’re expected to make struct types public in order to return instances You can return unexported ("private") instances; for example this is perfectly valid: type unexport struct { Str string } func (unexport) Method() string { return "export" } func NewUnexport() unexport { return unexport{Str: "asd"} } And you can get/set the exported Str field from another package without problems, as well as call the exported Method. You don't even need to make an unexport package type and can use an anonymous struct or type declared in the function too, although you can't add any methods like this and is often cumbersome because you need to declare the anonymous struct more than one. And, of course, you can make parts of a struct private by just not exporting them. It's really not all that different to how OOP languages work with public/private, except that visibility is dictated in the name itself.