> The issue isn't interoperability, the issue is compatibility. Is it
> possible in OpenStep now to use C++ *syntax* to access Objective-C objects?
> In other words, do I *have* to use [someObject someMessage:anArg] to send a
> message to an Objective-C object, or can I accomplish the same thing with
> someObject->someMessage(anArg)? Can I subclass an Objective-C class in C++?
Its a common problem with NextStep since people always miss a little
detail that makes so much of a difference.
OpenStep Frameworks really _are_ the operating system.
(at least they are a core part of the systems functionality
and the same objects come with every machine and therefor are
core OS features)
IMHO this is a very crucial point when we talk about Rhapsody. Its not
the BSD C APIs or the Mach C function bindings or direct DPS context
communication which we should consider as the OS API...its OO frameworks
which are written in a specific language (here ObjC) and therefore can be
accessed naturally using that language.
Now nobody seems to have a problem that early systems used stack based
trap style OS APIs to access OS functionitly. There it seems just natural
to everybody that in order to use C++ you need C++ frameworks to shield
you from low level communications with the OS. (since that MAc was Pascal
in the early days...you still have to pass Pascal strings when doing
C++... or you have some wrappers which take care of the conversion)
Now think of the C++/ObjC interoperability as the low level communication
but if you want to do C++ only you need a C++ framework that shields you
from pure OO communication (wreaps those "ugly" ObjC messages)
Using ObjC has the benefits that you can easily customize the operating
system since you can replace or remap certain OS behavior jsut natureally.
C++ lacks certain features that ObjC offers at the language level so you
need some meta-programming to solve these issues and you need a "smart"
C++ compiler which knows who to generate code blocks that can 2patch" your
system (which would mean repackage in an operating system conform runtime
fashion...which happens to be the ObjC runtime)
> I don't have a problem with using or learning Objective-C to develop for
> Rhapsody, but many other people appear to want to actually use C++ to
> program Rhapsody, not just to program the non-interface portions of their
The "none-interface" argument always comes from the fact that there are
(yet) no C++ wrappers for the operating systems (OpenStep ObjC)
frameworks. Since C++ and ObjC integrate quite nicely...and the ObjC tools
enable rapid GUI development most people took the "interoparability"
You are free to write a C++ wrapper to the AppKit...and MetroWorks will
propably offer a C++ framework which sits on top of the ObjC classes and
not the core C-function services of Rhapsody. Not sitting on top of the
operating system objects (which happen to be ObjC) would require to
dublicate multilanguage support, window handling, etc. pp.
This programming language confusion seems to be really big.
This is why Apple emphazized the "Java" mappings and "Java" programming.
Even Java has to interface to the operating systems...but since there is
a simple way to map ObjC to Java programming in Java is a very natural
thing under Rhapsody.
So Java gives you "Java-OS-wrappers" almost for free...
...while C++ does not. C++ just offers easy interoparability and it takes
a good C++ framework to shield you from "low-level OS communication"
(using ObjC code).
So what if Apple called their OS. "The first PDO-based OO OS". (replace
PDO with CORBA to get it sound "hype-right"...or call it ObjC-runtime to
get it technically more corerct).
Now lets say Apple currently only offers an ObjC binding to the
PDO-language-neutral system object model (yet another SOM system).
Interestingly ObjC interfaces very well with Rhaspodies object runtime
since all frameworks happen to be in ObjC and the OS'es runtime uses the
same features. Which means a 100% OS object model to programming language
mapping (similar to Java-OS/VM + Java).
Now if you have a "Direct-To-PDO" C++ compiler things would be just fine.
Wouldn't they ?
I personally don't understand the "language" confusion which seems to be
worrying Mac developers that much. There was Lisp, Smalltalk, Eiffel,
Oberon, Scheme, and many more.. available for NextStep and you could write
No matter which language (read "object model") Apple would have picked
for its next OS...usually its "natural" OS language which is the most
elegant for the system (like PAscal for the Mac) until the other language
tools and frameworks managed to wrap all OS services.
Rhapsody developers will be able to program in any language they want
once the tools have been ported, but ObjC and Java (and other dynamic OO
languages like Smalltalk) should be the most natural.
To summerize it...take a look at Rhapsodies "assambly" language
(ObjC)...if its doesn't meet your requirements...use a different language.