In article <[EMAIL PROTECTED]>, "Pierre Phaneuf"
<[EMAIL PROTECTED]> wrote:
> 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.
You obviously know what I meant to say, but to be clear, my comment
should have read "would", not "wouldn't".
>> 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).
Right, but even there the old interface is still frozen (for all intents
and purposes), though the implementation may have changed. In such cases,
care must be taken to ensure that the semantics behind the old interface
remain unchanged (from the previous implementation) as well.
--
Braden McDaniel It is hard to know if nothing is /
http://endoframe.com actually nothing
e-mail: [EMAIL PROTECTED] And thus difficult to know if a policy /
Jabber: [EMAIL PROTECTED] of doing nothing is successful
-- Radiohead
