4 ms·
Hi, I enjoyed your article. You have some good points about tiny types, but if you read through the code in the Go standard library, you won't find this style
by echlebek 11y ago
Hi, I enjoyed your article.
You have some good points about tiny types, but if you read through the code in the Go standard library, you won't find this style applied in very many cases. Typically, only if one wishes to attach a method to a built-in.
As another poster rightly pointed out, it complicates the documentation quite a bit, and I think a lot of Go programmers would consider it pointless abstraction.
// NewBox creates a new Box. It returns an error if length
// or width are less than or equal to zero.
func NewBox(length, width float64) (Box, error) {
...
}
Consider the simplicitly of NewBox. We may omit a Length and Width type, and any validation of these by stating the expectations of the inputs in the documentation. So, the API is dramatically simpler. The expectation is that the programmer will not pass invalid arguments to NewBox, by way of common sense or reading the documentation. Programmers who pass in positive numeric literals may even opt to ignore the error returned, since the documentation states the the only reason an error would be returned is if the input parameters were <=0.
Go puts a big emphasis on documentation, and this often compensates for lack of power in its type system.
- guntars 11y agoTo me the perfect example of when you want to use tiny-types is when dealing with values in different units, say, temperatures in Celsius and F. They're both floats, but mean very different things. The extra typecast you have to do before calling a function with a float is a good sanity check.
- codygman 11y ago> Go puts a big emphasis on documentation, and this often compensates for lack of power in its type system. This could be reworded to: > Any language X that puts a big emphasis on documentation compensates for lack of power in its Y. I disagree this is true for those languages including Go.