On Sun, Jan 28, 2001 at 03:53:28AM -0500, Braden McDaniel wrote:
> In article <20010127203640.C422@andrew>, "Ari Heitner"
> <[EMAIL PROTECTED]> wrote:
>
> > - if you depend on a component, *know* which library that component
> > lives
> > in. Play games if you have to (bogus symbols or something) to *make
> > sure* that your executable shows linker-level dependency on that
> > library. this is just a matter of keeping dependencies transparent.
>
> Um, yuck, I think. One of the main problems COM solves (or at least
> attempts to solve) is that of binary interoperability. Are you asserting
> that that problem should not be solved (or that it should not be solved
> the way COM does it)?
What is the "binary interoperability" problem? I just don't see the
conceptual restriction of "I depend on this functionality, which lives in
this library". Anyone can implement a hardware libGL.so or a distributed
rendering one or whatever -- but it always contains the same symbols, and
always has the same library name.
I see the COM point of hacking around compiler-specific name mangling -- but
why not then provide in-library extern "C" factory functions, and use
COM-style specified-vtable-format interface-only objects? You *still* know
that IFoo lives in libFoo.so etc etc.
I simply don't see the advantage of divorcing a compile-time-specified
link. Maybe i'm missing something here?
>
> > - obviously if your application ships with a pile of libraries, it's
> > reasonable to assume they'll be installed in the way the application
> > specifies.
> >
> > For that matter, it wouldn't be at all unreasonable, as
> > COM/CORBA/whathaveyou grows on Unix for some formal specification of "I
> > depend on this UUID" to grow, so that dependencies are apparent to the
> > packaging system. Having the dependency be runtime may be necessary, but
> > *no* program should ever be installed without all its depencendies met
> > ...
> > that's a "civilized system" issue.
>
> As long as the UUID refers to an interface and not an implementation, I
> agree. (But I think you really mean for it to refer to an implementation.)
Yeah yeah absolutely :)
>
> I don't have quite the animosity toward the notion of frozen interfaces
> that you seem to have. The system does seem to have been designed for
It's not an animosity -- I just argue for simultaniety. There should be a
stable interface-frozen current version, and a development version (which
many people may choose to run). The stable version has (nearly) frozen
interfaces (i say nearly because occaisionally backporting stuff from the
new version makes sense; the example here is the kernel) and the devel
version has zero guarantee of interface stability.
I think such a model is a miserable form of existence :)
It's also the only thing I've seen work.
...
The one Booch/Box/Gamma book I *really* buy all of is "Extreme Programming",
one of the premises of which is [paraphrase] "locking down designs too early is the
primary cause of project failure". Note that this is the same as
"worse-is-better"! It's also something Linus says a lot. It's also something
Jaron Lanier harangues about. So yeah, I think of interface-freezing as a
necessary evil.
ari
