Re: [Q] COM and dynamic link library?
Re: [Q] COM and dynamic link library?
- Subject: Re: [Q] COM and dynamic link library?
- From: Scott Thompson <email@hidden>
- Date: Tue, 18 Apr 2006 22:15:16 -0500
On Apr 18, 2006, at 4:15 PM, JongAm Park wrote:
Hello, all.
I would like to ask a fundamental question regarding to the COM. I
am sorry that I couldn't find a dedicated USENET news group for
COM, so I added microsoft.public.vc.atl and vc.language where it
looks OK to ask about the COM.
I found out that the Plug-in architecture of the Cocoa uses
Microsoft's COM model.
What you have likely found is the CFPlugin architecture. CFPlugin is
part of the "Core Foundation" layer. This is an application
interface layer that you might say "sits underneath" Carbon, Cocoa,
and the BSD appliations layers.
In a true Cocoa application, where you the dynamic runtime of
Objective-C at hand, I would be surprised if a developer would choose
to use CFPlugin directly.
Having said that, the basic binary-level transport mechanism is not
all there is to "true COM". CFPlugin makes use of the basic
transport mechanism and borrows the IUnknown interface, but COM on
Microsoft platforms encompasses quite a bit more. CFPlugin has it's
own instance creation mechanism where COM on Windows uses
CoCreateInstance and friends. You could say that CFPlugin uses the
fundamental mechanism of COM, but I would not call CFPlugin an
implementation of COM on the Macintosh.
According to an article read at the Oreilly's site, it can be only
used in dynamic link library. Because you don't need to link it
with other languages like BASIC, the COM model may not be
appealing. On Mac OS X, the location transparency is not supported.
Well, because there is RPC and messaging API, it may not be a
problem at all on Mac.
OK. Here is my question. What is good reason to use COM model in
general?
Let me preface my remarks by saying up front that I am not a fan (at
all) of the COM model. In general, I have never heard a good
argument in favor of interface inheritance (to the exclusion of
implementation inheritance). My past experience with COM has been
that while it works, using it is unnecessarily painful and annoying.
Having said that. One reason to to implement COM is it's
simplicity. At it's heart, COM is based on little more than a table
of function pointers. It's hard to come up with a more simple
construct in C that has the same functionality as a COM interface.
Implementing just enough COM to get the basic object communication
path in place requires no special runtime support beyond that which a
C compiler can provide.
That means that it's easy to integrate that level of COM into a broad
variety of languages and (presumably) different computer architectures.
(The object binding layer in Objective-C is marginally more complex
than the simple ABI of COM, but it's still "simple enough". I'm
surprised there are not more languages that compile down to the
Objective-C runtime.)
The major reason can be modular programming and programmers can
share the same interface with different programs.
However, if they can share source codes, then wouldn't it be
suffice to share the codes?
To share code, the different components would have to be written in
the same language. If one is written in C++ and the other is written
in Smalltalk then it is not possible to directly share code between
them. The two need a common medium in which to exchange information.
The simple ABI and IUnknown interface of COM allows for this exchange.
Or.. if they can't, i.e. probably developers of one company don't
want to reveal the implementation to other developers of other
company for many reasons, wouldn't it be OK to implement it as a
library, whether it is static or dynamic, and provide header files?
Even when you use the COM, you should give interface files to
others. Wouldn't it be possible to put classes into a library? So,
there is no problem with OOPness. You can also load them on demand.
( But for libraries, it is per-library rather than per-object. )
To continue my example, Smalltalk and C++ use very different object
models. You can do things in Smalltalk (or Java, or Objective-C)
that you can't do in C++. Yet having a common exchange mechanism
(i.e. COM) would presumably allow C++ applications to make use of
components written in Smalltalk, or vice-versa. This is somewhat of
an extreme example (exaggerated for effect) but hopefully you get the
idea.
Even if the component and the application are both using C++,
however, you still have the fragile base class problem to contend
with. If the component developer changes their library in such a way
that the header file changes, the application developer would have to
recompile their application to adapt to those changes. COM allows
you to revise the interface of the component, while maintaining the
old interface for existing client applications.
Especially for Objective-C developers, a class can be expanded
horizontally using the category and the protocol mechanism as well
as vertically using inheritance. So, Objective-C already provide
very efficient and elegant mechanism for modular programming.
This is true. I would venture to say that very few Objective-C
applications would make use of CFPlugin simply because Objective-C
provides a much more straightforward (and infinitely easier to use)
mechanism. In fact, this is one of the most valuable, and to my mind
under-exploited features of the Macintosh environment. Objective-C
provides for lots of really nice features, a object communication
mechanism, an RPC mechanism (through NSProxy), Introspection through
the runtime, and dispatch services (through NSInvocation). I'm
surprised that there is not more component software for the Macintosh
platform.
I've often speculated that what may be missing is a component
framework (if you'll forgive the heresy... a la OpenDoc... but
without the irrational marketing hype)
To Windows programmers, they may need COM interface, because many
of them are Visual Basic programmers. However, wouldn't it be
possible to rewrite the Visual Basic compiler/VM to understand the C
++ header file?
Potentially, but C++ is very fragile when it comes to changes in
implementation. When the ActiveX control that draws the calendar in
your Visual Basic application changes, you don't want to have to
build your application.
COM allows you to change the implementation of your component without
having to recompile every application that makes use of it.
You know, Java can call C/C++ codes and C/C++ can call Java codes.
Don't you think that MS manipulated the necessity of the COM?
(Well.. there are other COMs like the Mozilla's XPCOM, and CORBA's
own, though. )
WRT to Java, a better question would be why do we need C# and .Net.
Why is the COM necessary?
COM provides a language independent and robust (if supremely annoying
and hard to work with) object transport mechanism that is not as
fragile as direct connections between objects.
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden