Platform Object Model [was: Re: CORBA with Mac OS X]
Platform Object Model [was: Re: CORBA with Mac OS X]
- Subject: Platform Object Model [was: Re: CORBA with Mac OS X]
- From: Scott Thompson <email@hidden>
- Date: Mon, 22 Oct 2001 10:14:40 -0500
Hmm, I'm surprised I haven't heard the suggestion yet, but one could
always write C++ wrappers for Objective-C classes & thusly act as a
bridge for the functionality. A better solution would be if we could
just get an Objective-C mapping going...
Since I first learned about it, I've thought that Objective-C's object
model might make a good system-wide object model that one could build a
component framework on top of.
Basically I think that Apple put the wrong marketing spin on OpenDoc and
that the technology was reasonably sound but pushed in entirely the
wrong direction. I think that a system-wide component architecture is a
Good Thing (look what benefit COM developers have gotten on Windows...
even if COM is kinda going out the window now). A component framework
like OpenDoc, properly directed, could be a really great addition.
The Objective-C runtime architecture suffers just a bit from a couple of
things. First of all, it's tied to the Objective-C language at the
moment (one can argue that the Objective-C to Java bridge opens the
model to Java as well) . As you suggested above, one can make different
language bindings through careful programming, but the entire process is
a bit too manual for my taste.
I thought it might be a nice idea to take a page out of SOM's book and
create an IDL-Objective-C compiler that could generate language bindings
for several languages. SOM's IDL compiler could do C++ and Smalltalk as
I recall... A new IDL compiler could generate C++, Java, and
Objective-C pretty easily (maybe Pascal if it could be show as a
beneficial addition) allowing for the intermixing of those languages.
Of course the C++ language binding wouldn't be "complete" (it might not
give you full access to the runtime) because of difference in the
fundamental object models of C++ and Objective-C, but it could be close.
Once that was done, you could begin building a component framework that
would allow for the developement of common plugins, runtime-additions
and the like where the standard communication mechanism was the
Objective-C runtime and the loader functionality of dyld. Such an
architecture is likely to have to have some registration mechanism for
components, services for instantiation, introspection mechanisms,
etc... Maybe Java Beans could serve as a starting point (Objective-C
Beans sounds a little silly though).
Just a somewhat-idle thought.
Scott