Re: [Q] COM and dynamic link library?
Re: [Q] COM and dynamic link library?
- Subject: Re: [Q] COM and dynamic link library?
- From: Greg Herlihy <email@hidden>
- Date: Wed, 19 Apr 2006 03:21:58 -0700
- Thread-topic: [Q] COM and dynamic link library?
On 4/18/06 8:15 PM, "Scott Thompson" <email@hidden> wrote:
> On Apr 18, 2006, at 4:15 PM, JongAm Park wrote:
>> 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.
Objective-C does not solve the version problem directly. The versioning
problem is simply how to coordinate the interface that the plug-in uses with
the interface that the host supports as either the plug-in or the host
application (or both) are updated and improved.
COM solves the versioning problem by adding a layer of indirection between
the client (that is, the plug-in) and an interface (in this case the plug-in
API). So instead of making hard-coded calls to the plug-in API, a plug-in
first asks the host for a particular interface (identified by a globally
unique id). If the host has implemented the requested interface, it returns
an interface pointer to the plug-in (needed to call its routines) or a null
pointer otherwise. In this way newer versions of the application with the
improved plug-in interface can load older plug-ins, and older versions of
the app can load newer plug-ins that use the new plug-in interface when
available - neither of which would be possible in all likelihood without
COM's layer of API indirection.
Granted, one could use in Objective-C the "respondsToSelector" message as a
versioning solution, but doing so would require checking one message at a
time instead of an entire API at once. There is also the problem of
uniqueness - two different classes could respond to the same message in
different ways; just because a class responds to same selector as another
class, does not mean that the plug-in can count on the second class
interpreting the selector in the same way as the first class does.
>> 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.
Software components are intended to be interchangeable, and for two plug-ins
to be interchangeable they must both implement the same, standard interface.
Typically, plug-ins are swapped - not stacked - so each software component
has to provide its own, self-contained implementation anyway - or it
wouldn't be called a "component" in the first place. After all, the purpose
of interface inheritance is to guarantee substitutability - not code re-use.
> 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.)
Probably because Objective-C itself "compiles down" to C - the language that
implements the Objective-C runtime. In reality, Objective-C is not much more
than C with a good helping of syntactic sugar. So a better question would be
why Objective-C still offers only the funky [] syntax, and not something a
little more mainstream - at least as an alternative; and why there's no C++
interface (implemented with templates and operator overloading) that would
allow a C++ program to use Objective-C classes directly.
>> 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. )
A COM component is a dynamic library for all practical purposes.
Conceptually it's a library that contains other libraries. So the only
public interface that a COM object offers is the one needed to obtain the
interfaces for the other - more interesting - "libraries" implemented
within.
>> 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. )
COM was released in 1992. And there have been other COM implementations on
the Mac, Codewarrior IDE's plug-in architecture for example. Furthermore,
the JNI code needed to call C from Java or Java from C is much more
complicated and requires a lot more work than the COM equivalent.
> WRT to Java, a better question would be why do we need C# and .Net.
Possibly because some programmers prefer to code in an ISO standard
programming language (such as C++ or C#) and one that is maintained by a
neutral, international standards body, rather than to write programs in a
proprietary language (such as Java) owned by a single, commercial
enterprise. And the simple reason why Microsoft needed C# for .Net is
because Sun was able to prevent Microsoft from implementing it in Java.
>> 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.
In short, it solves the versioning problem.
Greg
_______________________________________________
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