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: Wed, 19 Apr 2006 09:05:45 -0500
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.
There's no need to resort to using "respondsToSelector:" for
individual method calls. You could easily use "confrormsToProtocol:"
to validate entire interfaces at once. Doing so is not unlike
querying for an interface, except that you don't need separate
pointers for the object on each interface.
But you are right that Objective-C in-of-itself does not solve the
versioning problem directly. A component framework would be a nice
addition in that regard.
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.
Well, in COM plug-ins are swapped, and not not stacked, simply
because there is no way to stack them. :-)
When developing components, there is no reason that each component
should have to be developed in a vacuum if the plugin architecture
can support inheritence. For example, if I squint my eyes and view
my application as a "just a an operating system plugin", using the
Objective-C runtime I am able to develop a custom window in my
application by inheriting from NSWindow in spite of the fact that I
do no own the NSWindow class. So long as I follow the established
protocols, my NSWindow is perfectly substitutable wherever NSWindows
are valid and I probably had to write a heck of a lot less code than
if I had to basically re-implement all of NSWindow myself in my
application.
If my application wanted to provide a "drawing tool" plugin, I can
use Objective-C and allow a plugin developer to inherit behavior from
my drawing tool class in much the same way.
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.
Don't confuse the Objective-C language with the Objective-C Runtime.
Conceptually, the runtime is easily separable from the Objective-C
language (though the reverse is not necessarily true).
From that standpoint The Objective-C Runtime is not "compiled down
C" any more, or less, than COM is. The runtime is based on data
structures that are in essence named tables of routine pointers just
as COM interfaces compile down to tables of C routine pointers.
The Objective-C language is a different issue. The language is
designed as an efficient way to create and work with the constructs
of the Objective-C Runtime. As you aptly note, it contains "syntax
sugar" to help facilitate that. However your ploy to use the age old
language war tactic of equating the language to its syntax won't work
any better now than it has in the countless number of times it's been
tried over the years. By your same logic, C++ is not much more than
"C with a good helping of syntax sugar".
Statements such as this are nonsensical. Like natural languages,
computer languages are composed of much more than just syntax. They
include pragmatic elements like single vs. multiple inheritance or
strong vs. weak typing, as well as idiomatic elements like templates
in C++ or protocols and categories in Objective-C. Those constructs
are typically what prevent one language from being represented
directly in another. They are also the elements of the language that
play the biggest role in supporting, or hindering that language from
serving well in a given problem space.
As I said before, I too am surprised that there are not more
languages and component frameworks built upon the Objective-C
Runtime. I suspect that that is the result of the size of the
development community, a lack of demand, and a lack of initiative on
Apple's part.
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;
Apple made an effort early in the development of Mac OS X to develop
a procedural syntax for the Objective-C runtime. The effort was
abandoned largely because nobody cared. The existing syntax is not
egregious enough to make the effort worthwhile.
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.
Simply put, there is great demand for such a beast. As far as I can
tell, there is nothing special about the Objective-C Runtime to
prevent any developer from creating such a thing. Doing so would
require quite a lot of thought and effort with little to gain from
it. It's much easier, and more direct, to simply compile some
Objective-C code into your application and be done with it rather
than trying to implement plumbing that must be maintained.
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.
No... Sun was able to prevent Microsoft from making Java, on their
platform, incompatible with the same Java that every other platform
used (and still be allowed to call it Java).
I don't think anyone believes that the development of C# was not done
for the altruistic reasons of providing developers with a
standardized language. Microsoft's biggest problem with Java was not
that it was controlled by a commercial enterprise, it was that they
weren't enterprise doing the controlling. While it is true that C# is
defined by a an international standard, one could effectively argue
that the language and .Net are, in practical terms, still controlled
by a single commercial enterprise. One day in the future, that may
change, but the pessimistic side of me says that if the standards
body moved in a way that Microsoft didn't like, there would quickly
be a C#++
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