[mcclim-devel] another CLC fix: clim-listener

[rpgoldman at real-time.com]

>>>>> "JM" == John Morrison <jm at mak.com> writes:

    JM> On Wednesday 15 March 2006 09:00 am, rpgoldman at real-time.com
    JM> wrote:
    >> More difficult (but possibly conjectural) what happens if
    >> *another* system you want loads cl-fad or spatial-trees and the
    >> version that other system needs is not congruent with McCLIM's
    >> requirements?  I know I always get a little nervous when
    >> asdf-install loads its private copy of cl-ppcre...

    JM> I am using McCLIM to graph cl-graph based graphs, and cl-graph
    JM> requires cl-fad.  So, basically, this problem is not
    JM> conjectural for me.

I should have been more clear.  The problem is conjectural in the
sense that we don't have a case (yet, AFAIK) where version conflict
arises.  E.g., where someone refactors cl-FAD, changing its API, and
cl-graph adopts the bleeding-edge version of cl-fad, but McCLIM stays
with cl-fad classic.

A counterargument to my claim would be "you should just always use the
latest released version."  I think in the large this approach is
losing.  But it's not clear that the CL community IS large enough for
it to be a problem.

This is a problem that McCLIM experiences, because it uses ASDF, but
it's really an ASDF problem, not a McCLIM problem.  

We (the CL community) are using ASDF as the equivalent of make + a
dynamic library loading system + something akin to rpm.  It's clearly
very good as a make substitute.  It's not clear to me that it's all we
need for the latter two functions.

best,
Robert