--- Begin Message ---
|
Subject: |
Re: accessor name clashes when using packages |
|
Date: |
22 Aug 2001 14:37:31 +0200 |
|
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Capitol Reef) |
address@hidden (Dave Pearson) writes:
> > > However, the next obvious question seems to be "what if the code comes
> > > from different sources and what if the code is seen, at least for now,
> > > as a black box".
> >
> > Then it's unlikely they really are managing the same GF, and so it's
> > unlikely there's a conflict.
>
> GF?
Generic function. It seems to me that there's a certain level of
talking at cross purposes going on, so I'll take the liberty of
retelling some of the things said in a different way:
- Your original problem is that two non-cooperating packages export
two "same-named" symbols. Then a problem occurs when you want to
use (in the use-package sense!) both packages in your own package.
The simplest solution of course is not to use (again use-package
sense) both packages, but rather to refer to one (or both) via
package prefixes (either via full package names, or more likely via
useful, (possibly locally defined) package nicknames). This IMHO
will also increase readability to the human reader, since he'll
likely be similarly confused as the CL reader.
A slightly more complex solution, but one which allows you to write
most code without package prefixes, would be to still use
(use-package sense!) both packages, and decide which of the two
conflicting symbols you want to be available without a prefix, and
which not, using SHADOWING-IMPORT (or more likely the
SHADOWING-IMPORT-FROM keyword argument of DEFPACKAGE):
(defpackage :my-own-package
(:shadowing-import-from :OTHER1 #:CLASHING-SYMBOL)
(:use :OTHER1 :OTHER2))
In this way no conflict arises, because everything can be
unambiguously resolved, since in MY-OWN-PACKAGE CLASHING-SYMBOL will
now be EQ to OTHER1:CLASHING-SYMBOL, and OTHER2:CLASHING-SYMBOL must
be accessed with a package prefix.
And if you don't want to favour one symbol against the other, you
can use SHADOW (or the :SHADOW keyword argument of DEFPACKAGE), to
force both SYMBOLS to be accessed with a package prefix, reserving
the unprefixed notation for a new symbol in your own package:
(defpackage :my-own-package
(:shadow #:CLASHING-SYMBOL)
(:use :OTHER1 :OTHER2))
All of these solutions don't require any form of source access or
source editing in foreign code.
- Since there is no general theory of merging different symbols into
one (which would require merging all of their properties, like
symbol-values, symbol-functions, symbol-properties, etc., as well as
violating many important identity-preservation laws), there exists
no general solution which will can let both OTHER1:CLASHING-SYMBOL
and OTHER2:CLASHING-SYMBOL be accessible in MY-OWN-PACKAGE without a
package prefix needed for disambiguation. This is no problem, since
the symbols in question aren't semantically equivalent (or at least
compatible) in the first place, hence merging would be a confusing
and dangerous thing to do.
- In your particular case, since the symbols in question only name
generic functions (here an accessors), which in this case don't have
overlapping definitions (methods defined on them), a specific theory
for merging those into one can be thought of, and people have given
you hints on how one might go about this kind of merging after the
fact.
- BUT, again, this kind of merging seems only defensible, IFF the two
generic functions are indeed semantically equivalent, i.e. the
operation defined by each GF (not to be confused by the actions
carried out by their methods) is semantically equivalent.
Since this kind of thing doesn't generally happen by accident, it
must be assumed that it was achieved by design. But in that case
the authors of the different packages should have cooperated some
more, and ensured that they defined their methods on one, shared GF
in the first place (which means one shared symbol), and hence your
problem would never have occurred anyway.
And if it did happen by accident, now is the time to reintegrate
this accidental discovery into the design of each package, again via
either cooperation between the authors (prompted by feed-back from
the user(s)), or through the users themselves if support from the
original authors can (no-longer) be obtained.
And if the GFs aren't semantically equivalent, then it would be a
grave error to merge them into one, regardless of which package they
were defined in (even if its the same package and different
symbols).
- AFAIU, the issue of coordination between authors for ensuring that
semantically equivalent things (like GFs) are defined on a shared
symbol, is what KMP was talking about. Without some form of
(out-of-band) coordination, it is not even possible to ensure
that the two things in question are indeed semantically equivalent,
and the package system issues are only technical side-issues in
that context. The package system ensures total isolation between
worlds automatically (if used correctly), without any form of
cooperation/coordination needed. When you decide to breach
that isolation in order to cooperate/coordinate, you must also
coordinate your actions through out-of-band channels, or else chaos
will ensue.
I hope this helps clear up some of the issues involved...
Regs, Pierre.
--
Pierre R. Mai <address@hidden> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
--- End Message ---