> on unix there is no magic: the assumption is that one compiler is used to
> build everything.
>
But that may not be the case if XPCOM can be turned into a system
architecture instead of just used for application plugins/extensions. MSCOM
is powerful because classes which are registered, are registered for the
entire system. Wouldn't it be nice to get this sort of component reuse at
the entire system level, not just for individual Mozilla type applications?
If that is to be done, then the components one person makes have to be able
to be shipped in binary and such. It is my understanding that this is
non-standard in the Unix world, but it is not impossible I don't think.
> on windows, everything uses the com format. remember, an interface is the
> same as any other object to the C++ compiler -- it just happens not to
have
> any data members. the layout of the data members is guarantee (afaik)
> because of C specs on struct layout. so yeah. *any* object you pass around
> will be fine, as long as it did the COM magic to make sure it's using COM
> layout.
Right, sorry. I keep wanting XPCOM to be more like COM I think. This is my
mistake.
> not interface based programming. the com layout itself. for a good
> discussion of this, read the first bit of Don Box's "Essential COM". he
> derives the reasoning behind COM basically by deriving an object format
that
> end-runs the intercompiler-compatibility problems for layout and RTTI,
then
> says "Look, we came up with COM!".
>
Yeah. But I think the primary issue is the static nature of interfaces,
which to me should be a tenant of interface based design, if it is to be
used in an "open platform" where different vendors can add different
objects.
> This can happen with interfaces time. What you're describing is a *policy*
> not a mechanism. It's COM design policy that internal representations can
> change while interfaces should remain constant. I can guarantee you that
> mozilla breaks the latter rule often enough :). and if you had different
> versioning on the interface header files, it would break your
intercompiler
> compat as well.
>
> in general tho if you're doing intercompiler stuff, the product is
decently
> released and you're only using the publicly exported interface headers.
even
> within mozilla, modules only share relatively stable stuff outside the
> module. so it shouldn't be a big deal.
Again you are right. MSCOM mandates that interfaces should not change, but
this is just policy. Of course, since MSCOM is everywhere at a system level,
if MS went in and changed interfaces willy nilly after release the result
would be a lot of neato components which all caused each other to crash. I
think maybe the fact that MSCOM is taken at the system level makes some of
these issues more apparent.
> "passing an interface" and "passing a pointer" and "passing a reference"
are
> the *same thing*. interfaces are *not special*.
Yeah, outside of policy, which the compiler couldn't give a hoot about, they
are the same.
>
> however, if everyone is playing by the rule that "interfaces are static to
> prevent headaches", then to follow this rule the correct thing to do is
pass
> an IUnknown and query interfaces down to what you need (checking errors
all
> the way). If you have the guarantee of interface stability, this
guarantees
> that the object will support the interface you want.
>
> but *all* objects *will* work (in a fundamental "compiler understands the
> object format" way) as long as they're declared with the COM declaration
> gobbledygood. So the only things that will break in mozilla are any
utility
> objects that are *not* declared this way. Note that you *don't* have to
> implement nsISupports (and therefore there's no overhead penalty for
> converting any malingering raw-C++ objects). And this will only work if
> everybody's got correct header files.
Right, but part of the COM gobbledygook declares that you must derive from
IUnknown (or nsISupports in the XPCOM case.) This allows COM to do a lot of
other really weird and interesting things (plus it is what allows XPCOM to
hook to Python, Perl, and also allows for the possibility of doing remote
calls.) I guess this is again just policy, and not enforced by the compiler,
but in the MSCOM instance, this policy IS enforced by the core stuff (in so
much as if you do not do this, then you will crash unless you are the
special case of being an in-proc, same apartment/context type of component.)
So I think we agree on all this stuff. I guess I mostly think that by
sticking to the MSCOM dictives of using only XPIDL interfaces (which are
derived from nsISupports) will result in a more stable and robust system. I
personally would like to see XPCOM expanded to the system level, but that is
because I really like the power afforded by COM, but I would also like to
freely develop on other platforms besides Windows.
Cheers,
Ken
