Re: [Q] COM and dynamic link library?
Re: [Q] COM and dynamic link library?
- Subject: Re: [Q] COM and dynamic link library?
- From: Ondra Cada <email@hidden>
- Date: Wed, 19 Apr 2006 00:44:18 +0200
JongAm,
On 19.4.2006, at 0:23, JongAm Park wrote:
Well, strictly speaking it may not be MS's COM.
Who knows. After all, say, the RTF format is, essentially, one of
theirs too :)
But please read this documents.
http://developer.apple.com/documentation/CoreFoundation/Conceptual/
CFPlugIns/Concepts/com.html
http://developer.apple.com/documentation/Cocoa/Conceptual/
LoadingCode/Concepts/Plugins.html
http://www.macdevcenter.com/pub/a/mac/2004/04/16/com_osx.html
Apple's document didn't mention that it is MS's COM clearly, but
anyway it shares the mechanism.
Am kinda busy, so I have scanned just the middle one, which seems to
be the only relevant to Cocoa. And it says
"In object-oriented languages, application developers define the plug-
in architecture—the shape of allowed puzzle pieces—by specifying
the requirements for a custom class. These requirements typically
take the form of an abstract base class or a list of methods (such as
an Objective-C protocol)"
and later on
"If you are a *Carbon* host application developer, you should
consider using the Core Foundation CFPlugIn ... *Core Foundation’s*
CFPlugIn is compatible with the basics of Microsoft’s Component
Object Model (COM) architecture"
(emphasized by myself).
I agree with your opinion in general. On Mac, it uses its own
mechanism for the Plug-In architecture, but at least it uses the
COM description.
Thus it seems -- exactly as I've said just before my blunder with
them darned contextual menus :) -- Cocoa has absolutely nothing to do
with COM. Just the low C/C++ levels exploit it (which is
understandble, for, short of designing their own scheme with roughly
the same functionality and without the compatibility advantage, they
can't do otherwise: the C++ runtime architecture is a disaster
unuseable for anything remotely dynamic, and whilst plain C could
exploit the weak linking for plug-ins, it would be comparatively poor
API).
By the way, no one answered my original question. I am still
anticipating your answer. :)
I though I did :) Since the question, IIRC, was
What is good reason to use COM model in general?
and I said (a) in Cocoa, there is no reason and COM model is not
used, whilst in Carbon the reason is it cannot do anything (much)
better, being limited by the poor C++ runtime design.
If you wanna see the concrete reasons why C++ runtime cannot be used,
well, it would be too OT here in my opinion; check e.g. for the
"fragile class" (and there's more problems than just that).
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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