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/CAOyqgcWArB%2BpF7kTrDtUK_ySXbf9XOHoP4gq47dy_Y6TmErzfQ%40mail.gmail.com.
