Braden McDaniel wrote:
> > 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.
>
> Because that wouldn't break locational transparency for the
> implementation.
I think he just doesn't see the usefulness of locational transparency.
It is thus useless to proceed on that subject without coming to an
agreement on the usefulness of locational transparency.
> > 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.
>
> I don't think a concept of "nearly frozen interfaces" is useful to
> (XP)COM. It's either in flux or it ain't. And if it's in flux, don't dare
> release any software that uses it. If it's frozen, it sure as hell better
> stay that way.
As explained in "Component Software", all you really need is for an
interface to be a "strict superset" of the older interface. As long as
you can use the newer interface in the place of the old one, you are all
right. This can also be defined as supporting both interfaces at the
same time (i.e. the new inherits from the old and QI answers to both
IIDs).
--
Pierre Phaneuf
http://www3.sympatico.ca/pphaneuf/
