On Thu, Feb 22, 2018, 12:43 <alex.rou...@gmail.com> wrote: > On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote: >> >> Have you read https://research.swtch.com/vgo-import? It talks about >> singletons and also how to solve that with different import paths. >> Note, that this is also independent of *how* the different import paths >> are represented and distributed; for singletons it only matters what import >> paths the compiler sees, whether they are committed physical directories or >> whether the vgo tool automatically resolves them. >> > > Yup, the package I'm working on really cannot have 2 instances even in > different import paths as it deals with a shared resource and code that > must be run on the main thread. > So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a > central v0 where all the v1, v2, etc.. packages import. >
Both seem fine. Daisy chaining would mean I would only have to code API translations for > the latest API but then it's debug hell and if one version in the chain > breaks, > it means fixing all the newer versions. Also there's a performance hit > going through many translations. > I don't believe so. There's may be an increase in compile time though. Note also, that you don't have to Daisy-Chain down - AIUI you can daisy chain up too. i.e. v1/singleton aliases into v2/singleton, aliases into v3/singleton... That way any cost would only be paid by people on stale versions. Yes, if vN breaks, that would also break vM for M<N, but IMO such is life, wenn you have different packages depending on one common one. But you wouldn't have to touch intermediate versions either. In general, this seems like a problem that should just be mostly avoided - if you absolutely have to have something like that, isolate the Singleton logic into a single, isolated package and try not to touch it, ever. And also, of course, don't constantly release new major versions. The real question though, is how other package management semantics would solve this better. Is this actually accidental complexity or just systematic complexity caused by "I need to both break compatibility *and* have different versions coexist *and* still share Singleton state between them? Having a v0 means non of all the daisy chaining problems but it means more > work when there's a breaking change as then I'll have to update all > versions. > Also it means that all version packages have to be from the same release or > it breaks. > > If I just have one module at the root, is it right to assume all sub > packages would be of the same commit and that there will be only one > version of the module? > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
