On Thu, Feb 22, 2018 at 10:27 PM <alex.rou...@gmail.com> wrote:
> On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote:
>> 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
>>> 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.
> I was thinking of cases where the behavior is so different it needed to
> emulate old behavior so over time all the emulation adds up and would be
> more complex than just emulating based on v0/latest.
>> 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
> The vgo blogs talk about coexistence of multiple versions so was just
> figuring out if it makes sense and how would that look like.
> I just like to be prepared for worst case scenarios, so stuff I was
> worried about may or may not actually happen. But better be safe than sorry.
Sure, I'm just saying that if you start with how you'd do this in a more
familiar packaging scheme, you might be able to transfer it to vgo - I'm
not convinced vgo makes this at all harder, it's simply a hard problem to
> 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.