"Adam D. Ruppe" <destructiona...@gmail.com> wrote in message news:it91me$b2g$1...@digitalmars.com... > Sean Kelly wrote: >> If we want to support using multiple versions of the >> same lib in an app then some more thought will have to go into how >> this will work. > > Versioning is absolutely trivial if the version is part of the > module name. > > This is a better way to do it long term too; it's future proof. > Download any module, no matter how old, and it will still compile. > > To update your code to the new version, do a "grep import foo_1" > and replace them with "import foo_2" and recompile. This is > probably less effort than actually updating your code to use > version 2!
First of all, that can't be automated reliably (at least not within reason). Suppose there's two spaces. Or (heaven forbid!) a tab. Or anything else that just happens to be non-standard that you just happened to not take into account in your grep line. Such as mixin-generated imports, which are only going to be more common now that there's going to be usable inside functions. Plus not everyone's a command-line whiz, which makes that a lot of manual tedium for them. Second, you shouldn't need to edit code to compile against a different version of a lib. I'm not *necessarily* opposed to the idea versions being part of the name (although it does prevent you from being able to reliably do an ordered comparison of versions unless you have a standardize naming scheme - in which case it's effectively not really part of the name anyway). But it shouldn't seep into the user code unless the user of the library wants it to.
