|
Linux Nazi posted:At no point do I ever need to pre-define a struct. I get that powershell is often regarded as a weaker language, and I'm obviously no developer so idk, I'm sure it is. But I can't believe that a modern language like Go is this much more cumbersome for basic JSON management. Go is very opinionated language. One of those opinions is that it's strongly typed and statically checked, like 99%. Like geonetix said you can use map[string]interface{} but Go is going to fight you every step of the way. Forcing you to cast and check when assigning to something not an interface{}. Go is going to push you to define a struct and say how to marshal the JSON to that struct. You can choose not to do this but since you are going against Go's opinion it's going to make it VERY difficult. The one up side to Go's opinion is that an "object.foo" was meant to be there because there's a struct that says "foo string" exists and a compiler checked it. With Powershell when you do "object.foo" does it work? Beats me, run the script and see. You can't know that "object.foo" is correct because the check is dynamic and has to checked at run time. How my job gets around making lots of structs is using Protocol Buffers and letting the protobuf library handle the marshal/unmarshal of data (both JSON and protobuf). I'm sure there's a Swagger->Go struct tool out there which will help. Ultimately, Go has very little support for dynamic programming unlike Python and Powershell which is strongly typed but dynamically checked) Honestly, pulling JSON into Go is probably the weaker side of the language. It can do it but it's not a great experience. It's better at receiving and returning JSON as a server, which is where the static nature of the JSON marshalling is great. Much easier to see where things changed IMO. As far as Powershell is a "weaker language" it's a language that is trying to solve a different problem. Doesn't make it better or worse and it's probably the "better" language for talking to random JSON APIs.
|
#
¿
Jul 9, 2020 18:25
|
|
|
|
| # ¿ May 11, 2024 13:10 |
|
|
Fluue posted:Should I: If you got with option 1 every time someone calls IsShiny a *rand.Rand() has to be passed in even if shiny has been set. I would go with option 2 and I would have two constructors. One is internal that’s used by the tests where a rand.Rand can be passed in. The exported constructor would not take a rand.Rand, make one, and use the internal constructor. This keeps it so your test (if in the same package) can set a predetermined rand.Rand but the caller doesn’t get to set anything. There’s no way to guarantee shiny isn’t changed in some code path internally. Go doesn’t have the concept of const or readonly. So basically you just have to make sure nothing sets it outside the constructor
|
|
#
¿
Sep 5, 2021 04:25
|
|