Re: against the components utopia

On Thu, Feb 16, 2006 at 09:31:50AM -0500, Lex Spoon wrote:
> Jamie Webb <j@xxxxxxxxxxxxxxx> writes:
> > [...] it /can/ be avoided for
> > Java and Scala /provided/ there's code in place to deal with
> > occasional incompatibilities when they do occur.
> 
> Do you mean, the person *installing* the components writes some code,
> as a last resort?  That would indeed be something I hadn't considered.

Sort of. Writing code would be a last resort solution to deal with
conflicting external dependencies. Bear in mind that conflicts
primarily occur between libraries, not whole applicatons. And just
installing two incompatible libraries isn't a problem either (provided
they aren't so impolite as to stomp on each other in the filesystem).
You actually have to try to load both of them simultaneously to
encounter a problem. This means that the developer of a package
that depends on two conflicting libraries is in a position write code
to resolve the conflict.

Often though, conflicts involve internal dependencies. If package
writers declare which of their dependencies are internal just as a
matter of course, and a linker acts appropriately, no-one need ever
notice that those conflicts exist.

I should emphasise that I'm not suggesting this scheme can prevent all
conflicts, but it may prevent or at least provide a route around most
of them. Here's the sort of situation I'm looking to avoid:

'stable' universe contains:
libA-1.0 (depends on libZ)
libZ-1.0

'libB-unstable' universe:
libB-1.0 (depends on libZ)
libZ-2.0

I want to use both libA and libB, so I create a union universe. sbaz
will have to install both versions of libZ, because it can't know
whether libA is able to use libZ-2.0 (can it do this? if not, that's a
separate issue). But I still can't load both libA and libB, because
whichever version of libZ appears first on the classpath will clobber
the other.

-- Jamie Webb