On Sun, 20 Nov 2005, Austin Ziegler wrote:

<snip>
> API versions are funny things. There should be language support for
> selecting a particular API version. Given a promise that certain version
> changes aren't supposed to affect the API, you can even select the
> latest version within a range of versions (RubyGems does this with the
> ~> version selector).
>
> If you don't have language support, then you're often left hoping that
> the user has the correct version installed or doesn't upgrade. You can't
> effectively lock your needs to a single version.
>
> If you can lock, then you either need packaging support for version
> resolution (e.g., to encourage the installation of the required package
> at install-time) or you're again completely at the mercy of the user
> *not* having installed the correct version and therefore being unable to
> use your library or application at all.
<snip>

it seems you are arguing for the existence of a linker.  i agreet that this is
needed - in fact i've written one for ruby!  ;-)  however, no linker that i
know of has anything to do with the language itself and merely resolves
dependancies between units of code written in some language and, often,
expresses them by encodings in some sort of object file.  assuming you mean
something different by "language support" then, can you give a concrete
example of the kind you are suggesting?


> Basically, we need core language support for versioning. 
<snip>

agreed.

i was asking for this in 2003 and designed the simplest possible packaging
neutral version scheme i could think of:

   see this thread:

     http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/e01c5c9e6c83d26a/4962fe022ee266a2?q=howard+fsl+library+linker&rnum=1#4962fe022ee266a2

     http://www.codeforpeople.com//lib/ruby/library/library-0.0.0/doc/


of course rubygems now supports a similar scheme of adequate power and i'm
using it several places (with the "~>" operator) to allow multi-versions to
co-exist on production machines.  it's a powerful and, imho, totally, 100%,
completely, absolutely essential feature for using ruby in a production
environment.  it's wholly unacceptable to say

   require "library"

and cross you fingers that you'll be loading one that exports the required
interfaces.  further more it must be possible you have two, or more, versions
of a library installed at once.


i manage about 50 packages on 100, or more machines and cannot imagine having
to update all code using "library-0.0.0" when installing "library-1.0.0" - my
approach has always been to install "library-1.0.0" in a way
(versioning/linking) that only new applications will use it and, over time, to
back port other codes to use the new library.  however, for a short or long
while both "library-0.0.0" and "library-1.0.0" must be able to peacefully
co-exist on my systems.  a selective versioning system is so critical i
cannot understand how others get by without it - what do you others do?  why
is this ability not seen as paramount to be adopted into the language (via
gems or some other mechanism) __asap__?  i'd given up whining for it myself
but this thread has given me hope that other people consider it as important
as i do.

kind regards.

-a
-- 
===============================================================================
| ara [dot] t [dot] howard [at] gmail [dot] com
| all happiness comes from the desire for others to be happy.  all misery
| comes from the desire for oneself to be happy.
| -- bodhicaryavatara
===============================================================================