Thanks, I'll rediscuss the risk with my team, maybe we can live with it. Btw, I prefer RegisterName, as long as we register in init, the program will crush immediately for a dup. On the other hand, Register exposes us to refactoring a type's name or to moving a type from package A to package B, implying we may fail on the decode at runtime for values encoded prior to the refactor.
gavraz On Saturday 24 August 2024 at 17:52:57 UTC+3 Ian Lance Taylor wrote: > On Sat, Aug 24, 2024 at 2:51 AM gavraz <gav...@gmail.com> wrote: > > > > 1. I attempted to wrap gob with my own package and specify a distinct > toolchain, hoping it would result in a fully independent copy of the gob > package in the compiled code. Thanks for the clarification, this approach > is a no-go. > > 2. The challenge with forking the gob package is the import of > "internal/saferio" in decode.go, along with maintainability concerns raised > by the team. Any workarounds? > > Well, you could copy the internal/saferio package also. It's pretty > small and doesn't have any other dependencies. I agree that this > approach is less maintainable. Perhaps it would be an acceptable > approach if your new code will eventually displace the old code. > > > 3. The problem we are facing is two-fold: first, we used Register > instead of RegisterName. Second, we have a primary decode flow that > mistakenly uses &target where target is an interface, which requires > registering even trivial structures. Developers have become accustomed to > registering every structure, and now we risk breaking the decode process > during refactoring due to path changes. Since I'm developing an independent > module, I’d prefer to start fresh and decouple this new module from these > side effects. > > It's not a problem for many different packages to call Register. They > will all get the same results. So the fact that there is a global > registry doesn't really matter as long as everybody only calls > Register, not RegisterName. So one option is to just not worry about > this. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a060c67b-a448-4287-993a-747d3cda1fb1n%40googlegroups.com.
