[Thank you for taking the time to answer my questions, very much appreciated.]
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? 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. By the way, my initial goal to find an encoding that offers: 1. Easy handling of interfaces (gob, zson) 2. Easy handling of maps with mixed value types (not zson) So, I ended up with gob but realized it will be safer to separate the current usages from the new module. Thanks. On Saturday 24 August 2024 at 02:39:23 UTC+3 Ian Lance Taylor wrote: > On Fri, Aug 23, 2024 at 4:26 PM gavraz <gav...@gmail.com> wrote: > > > > So gob has a Register function that mutates a "global" state. This > implies that a single program cannot have multiple instances with different > registrations. > > True. > > > I tried to create another module that wraps gob with its own go.mod with > a different toolchain then what my program uses hoping that gob.Register != > mygob.Register but no luck. > > I have a few questions > > 1. Why didn't the gob-wrap work? > > I'm not clear on exactly what you did, but in general there can only > be one package with a given path in a binary. And an entire Go > program must be compiled by a single toolchain. > > > 2. Is there a proper way to get two instances of gob? > > Well, you can copy the contents of encoding/gob to a different path, > and import from that path. The two implementations will be > independent. > > > 3. Why do you think gob/encoding was designed this way in the first > place? > > In general it doesn't matter whether different users of encoding/gob > use the gob.Register function. It's no big deal if the two users both > register the same type. > > On the other hand you can get failure if different parts of the > program try to use RegisterName with overlapping names. I guess the > expectation was that that would not happen in practice. encoding/gob > was designed and implemented quite a while ago, in 2010. We might not > do it the same way today. > > 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/2561a08e-edfa-49da-90c2-546a523aadc0n%40googlegroups.com.
