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: Wed, 5 Sep 2001 10:28:13 +0100
And so it was that Ondra Cada said on 4/9/01 8:24 pm:
>
Ken,
>
>
>>>> Ken Tabb (KT) wrote at Tue, 4 Sep 2001 19:16:57 +0100:
>
KT> And so it was that Ondra Cada said on 4/9/01 5:32 pm:
>
KT> >>>>>Jonathan Hendry (JH) wrote at Tue, 4 Sep 2001 10:21:26 -0500:
>
KT> >JH> >"Since a properly done ObjC-based API is *MUCH* better than a
>
KT> >non-OO JH> >one, it
>
KT> >JH> >is quite sad to see new non-OO APIs in Mac OS X:
>
KT> >JH>
>
KT> >JH> Ondra, you cannot say whether an API is much better or not without
>
KT> >JH> taking into account the requirements it has to meet.
>
KT> >
>
KT> >Requirements? To be used in quickly developed, as bug-free as possible,
>
KT> >easily maintainable and upgradeable code. I kind of presumed that
>
KT> >obvious.
>
KT>
>
KT> They might be *your* requirements (and indeed most other developers')
>
...
>
KT> they care about usage factors, such as runtime speed
>
...
>
KT> What about memory consumption
>
>
Ouch, please not *THAT* again. Those things as runtime speed, memory
>
consumption or package size I took for constant. Should I not, they would
>
go
>
in favour of OO applications too.
Ondra,
So how come OpenGL doesn't have an OO API? Maybe the OpenGL ARB are
stupid, or haven't considered it? Why isn't there an OO-hardware
accelerated OpenGL card? Or are we talking about a different type of
speed?
I'm not sure I agree about the package size and memory requirements
falling in favour of OO per se (sure they will in certain APIs, but I
don't think this would be true in all situations). For instance, subclass
an object and you inherit *all* of its methods / variables, even if your
running app only use 1% of them. Have N of those objects and you've
increased your necessary memory usage by N * size_of_unnecessary_bits.
That's a lot more memory than you may have needed, and is not the case
when using procedural APIs. Thus memory allocation is also slower in apps
which make heavy use of the API, as there's more memory to be allocating
/ paging etc. That's not to say the OO API can't be tweaked to help this
a bit, but that requires more work (on behalf of the API developer) to do
these hacks.
I'm certainly not trying to say that procedural APIs are better than
Object Oriented (far from it), just that each meets different
requirements, and some requirements (eg. speed, memory), are more
important in certain situations (eg. OpenGL graphics) than others. For
what it's worth, I'd far rather have faster computers and OO everything
(including QuickTime from Cocoa), so that we don't have to have the
procedural vs. OO debate. I know this previous sentence to be
incorrect... the minute people make faster computers, the minute the
procedural programmers will realise how much mileage they get out of
their app, so they still won't want to go OO.
You seem to now be claiming you'd assumed speed & memory factors, yet
you'd already listed those which you'd assumed. In my experience it is a
mistake to assume other peoples' requirements without consulting them...
saying "these are your requirements" as a first step generally doesn't go
down well and makes one appear inconsiderate.
Cheers,
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