PEP: import version

[Hung Jung Lu]

Christopher Barker <Chris.Barker at noaa.gov> wrote in message news:<c82sjs$qvm$1 at news.nems.noaa.gov>...
> A. Lloyd Flanagan wrote:
> > Using multiple versions in one program sounds like a recipe for
> > disaster to me, even with some sort of language support.  Also, we
> > shouldn't make the normal single-version case more complex or less
> > efficient to support a case that should be extremely rare.
> 
> However, you may be right that this is a recipe for disaster, and the 
> user of that module simply needs to test with the version they are 
> using,a nd if it fails, get an updated version of the module, so that 
> the whole program is using the same versions of everything.

It all depends on the specific problem. The need for heteroversion
applications becomes important in client-server architecture. For
various reasons (business, technical, or otherwise), clients may not
be updated immediately with each new release. Thus, the server needs
to handle requests with legacy I/O formats and/or with legacy business
logic. If well-done, heteroversion components can ensure a smooth
transition in upgrades. In long-running server processes, you really
would like to be able to switch dynamically between different versions
during runtime.

In principle, if a package is well-written as a heteroversion
application, then you could do something like:

import myPackage
myPackage.use_version('2.3')
... do tasks a la version 2.3
myPackage.use_version('2.4')
... do tasks a la version 2.4

Traditionally, Windows DLLs have a rudimentary way of implementing
heteroversion features: by creating more and more API interfaces,
while preserving the old code to make them backward-compatible. Thus a
new DLL is supposed to work in new and old versions of the OS.
Although theoretically sound, in practice this approach requires
high-degree of discipline. Therefore you get the well-known "DLL hell
problem". Microsoft has kind of decided that disk space is no longer a
concern, and has opted for independent assemblies for each version in
the DotNet world. Price to pay: if there is a bug that is carried over
several versions, you'll probably have to (1) work it through the
source code files of each version, creating branches (2) release
upgrades for different older versions. Instead of developing software
in time dimension alone, you now have a two-dimensional problem. This
two-dimensional problem should be well-known to people that release
software packages in multiple versions.

There is no perfect solution, no free lunch. Each approach (single
heteroversion application, or multiple versioned packages) has its own
benefits and problems.

But if the heteroversion approach is wanted, there are ways to do it.
Inheritance polymorphism is just one of the tools.

regards,

Hung Jung