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 16:26:37 +0200
Greg,
On 19.4.2006, at 12:21, Greg Herlihy wrote:
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.
Quite. Since that, it is not and conceptually cannot be a language-
based feature (unless you make a PL/1-like brute which would try to
base just all the possible things into the language, being thus of
course quite unuseable :))
For an excellent solution of this problem see file:///Developer/ADC%
20Reference Library/documentation/MacOSX/Conceptual/BPFrameworks/
Concepts/VersionInformation.html#//apple_ref/doc/uid/20002255
Granted, one could use in Objective-C the "respondsToSelector"
message as a
versioning solution,
Quite the contrary. This API (along with protocols etc.) is rather
aimed to functionality-based (rather than version-based) interfacing.
They are orthogonal: you need both, sometimes both 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.
Actually, it can, otherwise it is a design fault (either by naming
two distinct methods the same way, or by messing different modules
together). That's called polymorphism.
For example, knowing sweet nothing of the object you are
communicating with, you can depend on that isEqual: compares for
equality and returns a BOOL. If there is a class whose isEqual:
comptes a sum, it is just plain wrong. That, for a change, is called
encapsulation :)
... After all, the purpose
of interface inheritance is to guarantee substitutability - not
code re-use.
Both, actually.
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.
Quite wrong. It does not (compile to C) and is (much more than C).
That said, of course you *can* compile ObjC to C (just like anything
other, since C has the full Turing's strength). Also, you *can* write
OO code directly in C. Though, it would be extremely tedious and
error-prone: belive me, I've actually done that (the object-oriented
Epoc-16 operating system, which I've programmed in, was designed
exactly this way).
So a better question would be
why Objective-C still offers only the funky [] syntax,
For the very same reason there is anything but the machine language:
for convenience. The difference is vast.
... why there's no C++
interface (implemented with templates and operator overloading)
that would
allow a C++ program to use Objective-C classes directly.
For that would be impossible. Templates and operator overloading are
*static* features which *do not allow* interfacing. They are fragile
and extremely error-prone.
---
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