I would argue that they are not obsolete and do serve a purpose. If
they're exposing the value of a sub-layer with negligible expense while
maintaining the style (API spelling and parameter types) of the
framework layer, then they're doing exactly what a framework should do.
More significant to me is that going "beneath the framework" eliminates
the ability of the framework to expose functionality to your app over
time. It may be far fetched, but suppose that Apple decided to grant
Carbon applications some kind of CoreFoundation style retain policy for
all allocations. Not easy when everybody's skipping the API and going
straight to malloc.
You might say that's ridiculous, Carbon is a low level API that should
be as close to the system as possible. That's not true. Carbon is a
medium-level framework that translates the resources of the system into
Carbon-ese. Take the File Manager. You can skip the File Manager and
go straight to the POSIX layer, but by doing so you lose all of the
value-add that comes from the File Manager's savvy about HFS. Not to
mention its adherence to standard Carbon argument types.
I admit that the malloc/NewPtr case is sort of academic, which is why I
raised it more as a philosophical question than a condemnation of using
malloc. I still say don't switch from NewPtr unless you've got a good
reason. So far, I haven't seen evidence of a good reason, aside from a
(I think misguided) line in Apple's documentation stating that you
should do so.
Daniel
On Mar 31, 2005, at 8:14 AM, Scott Ribe wrote:
I don't think POSIX memory calls will be disappearing from Mac OS any
time
soon, but if you're programming with the Carbon API, why not stick to
Carbon
API calls?
Even ones that are totally obsolete and serve absolutely no purpose???
FYI:
I quite using NewPtr and switched to using malloc about 10 years ago.
Back
then there was a difference, and malloc integrated with the wide world
of
standard C & C++ libraries a heck of lot better.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
