Re: ObjC API != Cocoa (Re: Another controversial question)
Re: ObjC API != Cocoa (Re: Another controversial question)
- Subject: Re: ObjC API != Cocoa (Re: Another controversial question)
- From: Ken Tabb <email@hidden>
- Date: Tue, 4 Sep 2001 19:16:57 +0100
And so it was that Ondra Cada said on 4/9/01 5:32 pm:
>
>>>> Jonathan Hendry (JH) wrote at Tue, 4 Sep 2001 10:21:26 -0500:
>
JH> >"Since a properly done ObjC-based API is *MUCH* better than a non-OO
>
JH> >one, it
>
JH> >is quite sad to see new non-OO APIs in Mac OS X:
>
JH>
>
JH> Ondra, you cannot say whether an API is much better or not without
>
JH> taking into account the requirements it has to meet.
>
>
Requirements? To be used in quickly developed, as bug-free as possible,
>
easily maintainable and upgradeable code. I kind of presumed that obvious.
They might be *your* requirements (and indeed most other developers'),
but other people relying on the API might have different / conflicting
requirements. Sure upgradable code means fewer bugs and quicker release
of new version of app, and those labour savings may be passed onto the
user. But in the hand-to-mouth day-to-day existence of being a user, they
don't necessarily care about how much quicker the developer will be able
to knock out the next version, they care about usage factors, such as
runtime speed. You may have designed a killer app but if its performance
is bad nobody will use it (possible exceptions of MS products and Apple's
MOSXS file copying performance). It is often argued that part of OpenGL's
speed comes from the fact that it's a procedural API. Of course this
doesn't help the newbie OpenGL programmer understand any of it,
nevertheless it might make a faster (and therefore better playing and
more selling) game, or whatever.
What about memory consumption - users will have to buy more RAM if the OO
nature of the API eats memory etc. In many cases this is just a 'poor
programming when making the API' issue, but for some cases it's a real
factor. For instance (possibly rather obscure example) most OO Neural
Network APIs (and there aren't many) stop OO-ness at a certain level and
start using arrays of floats etc. for performance and memory reasons. If
the developer wants to get down to this level of the implementation,
they'll need to start doing the crunching too. That's taken the elegance
of the API away for those developers in that situation (and lets hope
they don't start changing things which will screw up other bits). The
other option is to have a fully OO Neural Net API which is limited in
terms of the size network it can build, purely so that it can operate
within the memory constraints of today's systems. This latter option
maintains the API elegance, but limits the potential market of any apps
built with it.
I'm not saying that these factors are more or less important than the
ones you list, just that they are factors nonetheless which will affect
some people more than others, so for you to say you kind of presumed your
factors were obvious might be an unreasonable presumption.
Personally I think we should make APIs really really hard for developers
to understand... like QuickTime / Cocoa integration without going through
Carbon 8^)
Ken
----------------------------------------------
Ken Tabb
Mac & UNIX Propellerhead & Network Bloke (Health & Human Sciences)
Computer Vision / Neural Network researcher (Computer Science)
University of Hertfordshire
e-mail: email@hidden
http://www.health.herts.ac.uk/ken/
Certified non-Microsoft Solution Provider