4 ms·
> the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties But that doesn't stop you from d
by thayne 2mo ago
> the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties
But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}.
> can't you build your own validator for that with the reflect package in the Add() method of your UI graph
Besides the fact that that would almost certainly significantly hurt performance, how would you be able to differentiate between unitialized data and data that was intentionally set to the zero value?
- olmo23 2mo ago> But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}. Static analysis tools can catch this, no?
- majewsky 2mo agoStatic analysis does not help if the type comes from a library and is _meant_ to be initialized using a literal. And then upstream adds new fields where the zero value is different from the previous behavior, causing users to silently drift away from the intended behavior. I had this happen to me with a type from std, and had to add a specific test to guard against it with future std upgrades: https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721003d3d035743b2ce1e71dd06f777cd568229ee191e46d5eac5f52532732R35-R52 https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721...
- duckbrain 2mo agoThat's a dependency making a breaking change, right?