Re: ObjC API != Cocoa [long, subjective]
Re: ObjC API != Cocoa [long, subjective]
- Subject: Re: ObjC API != Cocoa [long, subjective]
- From: Brent Gulanowski <email@hidden>
- Date: Tue, 04 Sep 2001 18:16:00 -0400
>
From: Finlay Dobbie <email@hidden>
>
>
On Tuesday, September 4, 2001, at 09:09 am, Ondra Cada wrote:
>
>
> (ii) BSD/posix and Carbon are compatibility Mac OS X APIs. They are
>
> C/C++
>
> based, and offer subsets of the OS functionality needed to maintain the
>
> aforementioned compatibility with Mac OS 9- (Carbon) or unix (BSD/posix)
>
> sources. If something over that is needed, Cocoa API can be used.
>
>
Wrong. BSD/posix is the really native API of Mac OS X if you look at
>
things one way, and Carbon is the really native API if you look at it
>
the other way. It's all really rather subjective.
>
I don't think the term "native API" has much value in these discussions. I
can't think of a non-native API, and don't suggest Java! :) We all know that
the software exists in layers, at least conceptually, and that the core bits
of code are procedural. The only "native API" that I've ever heard of is
machine code, but who's going to use that anymore? Well, the compiler
writers.
But this is Cocoa dev, so what we want is the ability to access as many
standard and ready-made tools as possible with a consistent set of
semantics, a consistent set of fundamental types and objects, and a
consistent means to organize system resources such as memory, process
threads, communications interfaces, you-name-it. Preferably they will look
like objects, and they will conform to the Obj-C language and runtime.
That being said, lots of people still use the C stdlib and stdio in their
Cocoa programs, and will continue to do so I'm sure, along with numerous
other pre-existing code which is straight C, or looks like C, as well as
other Obj-C code, and pretty soon C++ code. Apparently some tasks are best
handled by different languages, and the interfaces reflect that. What
affects the useability of these code libraries is how efficient and
effective they are, and I would guess that this depends upon not only how
buggy the code is, but how many side-trips are taken between other code
libraries before the actual numbers finally get crunched and the desired
output gets generated and presented to the user.
Then it's just a matter of style whether the different code resources you
are accessing have a C, C++, Obj-C, Pascal, or even LISP interface, and
whether or how much behind-closed-doors tricks and hacks are being used by
the OS/runtime to make it actually link and function. I am totally on the
side of those who want consistency in this respect, but with such a large
body of pre-existent code-base, it's going to be a long time before it gets
standardized, if ever.
So I would think that the best thing to do is to write the minimal
object-interface you can, keep all of the non-OO stuff hidden behind that
breaker wall, make sure that the wall is good and strong, and then go back
to what you were doing. Fortunately, since Obj-C shows a strong sense of
consistency in the design and nomenclature, if Apple or somebody else makes
a better abstraction layer, it should be very similar to what you come up
with if you follow a consistent set of design and nomenclature principles.
Better yet, beat Apple to the punch and write something so good that they
want to buy it from you. They've got the money. Alternatively, be a saint
and give it away for free under the LGPL :).
What would be nice is if it were made a lot more clear by Apple _exactly_
where and how all the pieces of library code fit together, and where they
are being made to fit by kludges instead of a properly designed and
implemented architecture. They should announce a road-map for fixing the
kludges and adding OO abstraction layers in the places it does not yet
exist, and start discussions with other companies who may be happy to
contract out or otherwise do the work instead of Apple without fearing Apple
will come in later and make them obsolete. The point is to save us work and
make it easier for us to make good apps that we can sell and help the
platform sell and make Apple and us money, right? Oops, sorry, I mean make
computers easier to use and the world a better place :). (Hey, I really want
to write software to run space probes.)
If they can't get that abstraction layer to cover enough functionality, app
makers are going to ask themselves why they should bother learning a new set
of APIs when they'll still be using the old ones half the time and be forced
to figure out how to mix them properly. Meanwhile Newbies like me are asking
themselves how many languages and inconsistent APIs they will have to learn
just to do something reasonably interesting that also preserves the look and
feel of the Mac we love. It's an uphill climb. I know Apple is working to
make it less of a hassle, but I wouldn't mind some advance notice of what's
going on. They were off to a good start with the OS X early discussions and
all that, but now it seems to have dried up. What's Mr. Tevanian got up his
sleeve? That's what I wanna know.
Brent Gulanowski