Re: [Q] COM and dynamic link library?
Re: [Q] COM and dynamic link library?
- Subject: Re: [Q] COM and dynamic link library?
- From: JongAm Park <email@hidden>
- Date: Tue, 18 Apr 2006 20:34:06 -0700
Thank you, Scott.
So, the most important issue is a fragile class and language
independence, according to your explanation.
Yeah.. those are reasons.
Under some situation, it is required.
Yeah.. but I saw many people who preferred writing as COM, although
their code base were not big enough, and there were not so much
necessity of code sharing. Probably they are just addicted to COM.
Thank you again for your explanation.
JongAm Park
Scott Thompson wrote:
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
--
±ºÀÚÀÇ ±³Á¦´Â ¹°Ã³·³ ´ã¹ÚÇÏ°í, ¼ÒÀÎÀÇ ±³Á¦´Â ´Ü¼úó·³ ´ÞÄÞÇÏ´Ù.
-- ¸í½Éº¸°¨ ±³¿ìÆí
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=++=+=+=+=
JongAm Park Home : http://my.dreamwiz.com/jongam
Blog : http://jongampark.blogspot.com
Tel)213-251-9592 MSN : email@hidden
H.P)213-820-8943 AIM/iChat : JongAm
_______________________________________________
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