Being able to add a field to a data type and having the compiler tell you everywhere you need to update the code is a huge productivity multiplier. It’s a shame when languages forego this advantage.
-
-
Replying to @pcwalton
One of my biggest complaints about Go. At work, we have a test helper (built with reflection) that verifies that a particular value has no "zero" values. You can then write tests will fail automatically if a new field is added and a constructor (or similar) weren't updated.
1 reply 0 retweets 13 likes -
Replying to @burntsushi5 @pcwalton
But there's a lot of ceremony behind using it, so in practice, the fact that the compiler doesn't fail when a new field is added ends up pervasively influencing API design. There are upsides to it, but on balance, I'd rather do without automatic default values everywhere.
1 reply 0 retweets 10 likes -
Replying to @burntsushi5 @pcwalton
Scala dev and I hate default params. Person sees a method is used 100x and doesnt want to update call sites / tests, so adds a default for their one case. In a few months, thing now has 5 default params and a bug where someone didn't notice a default was wrong for their call
2 replies 0 retweets 1 like
To be clear, that's a different problem, if I'm understanding correctly. That's an opt-in thing you can choose to do. In Go, you can't opt-in or opt-out of default values for structs. It's a core part of the language.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.