Can you please elaborate on the comment that Apple is "now
effectively end-of-life-ing Carbon"?
Read the archives of this list. Especially the thread about 64-bit
Carbon.
All due respect, I'm not looking for a treasure hunt. I have already
spent some time with Google and the mailing list searches, and did
not find what I was looking for. I'm looking for some definitive
statement from Apple regarding the future of Carbon.
And not that I really intended to get into a language-comparison
debate, but I'll be happy to offer clarifications regarding my comments:
I'm specifically annoyed by what I've learned about how Objective-
C initializers have to be manually, explicitly managed relative to
the inheritance hierarchy (heck, even the ancient C++ model
doesn't allow for back-door construction via a base class
constructor),
Not quite sure I follow you. In C++ you also have to call through
to the base class constructor unless you have no parameters to pass.
My reading of this page (see Figure 4-2 in particular)...
...is that if I have class "Base" and class "Derived", and if Base
handles message "init" but "Derived" only has "initWithFoo", someone
can still call "[Derived init]", resulting in an incorrectly
initialized instance of "Derived" (because no initialization method
of "Derived" has been called).
In C++ (and other OOP languages), you define constructors that are
closely tied to object instantiation, and when instantiating a class
you must use one of the constructors defined explicitly in that class
(unless no constructor has been defined, in which case many languages
allow for the default constructor of course). The language
automatically ensures that all classes are always constructed in a
well-defined way. If you define one or more constructors for a given
class, the class cannot be instantiated without using one of those
constructors.
I gather from the above reference that this is not true in Objective-
C. It is up to the person implementing a class to cover any super-
class initialization methods to ensure proper object initialization.
If one wants to be strictly correct about the requirement, they
actually need to double-check the entire inheritance chain, because
some class within the inheritance chain could have failed to comply
with the rules and not covered some initializer it should have, which
would then need to be covered in the most-derived class to ensure
consistent initialization of the most-derived class.
I'm not saying there's anything fundamentally wrong with this
design. I am largely language agnostic, and have found that you can
do just about anything in any language. But as a programmer, I
prefer to have languages that implement de facto rules as strict
compiler requirements. That is, if there's a convention that must
always be followed in order for the code to be correct, then the
compiler should simply enforce that convention, and where possible
_implement_ that convention on my behalf.
I'm not calling Objective-C broken, but I am saying it doesn't suit
my preferences very well.
And it's a feature that you can decide what object to create
without the caller having to know they're getting another object.
I'm not talking about that, as I hope you now understand. Though, I
have to admit, it's a little unsettling that Objective-C also allows
for object replacement during construction. :) Still, that part of
the language doesn't really bother me at all, as it requires no
additional effort on my part, nor does it seem likely to introduce
subtle bugs, and it could actually be useful at some point (though,
lots of other languages do without, requiring that one simply use a
class-factory paradigm in scenarios where that might be needed).
[...]
You may want to listen to my explanation of Cocoa memory
management (and memory management in general, including debugging
memory) on the http://LateNightCocoa.com Podcast. There's really a
very simple set of rules behind this, and apart from one or two
tiny exceptions (which are probably only there for historical
reasons, i.e. look like they were mistakes), everything follows
these rules.
But they are just conventions. That's the problem, IMHO. They are
conventions that are basically required in order to produce
consistent, bug-free code, but not enforced by the language itself.
And the fact that there are _any_ exceptions is cause for concern,
because rest assured, it's those exceptions that are going to have me
scratching my head late one night trying to figure out why I'm
leaking or corrupting memory.
IMHO, compared to C's manual memory management using NewPtr()/
DisposePtr() and the likes, ObjC's reference counting/pools system
saves you a lot of hassle worrying about ownership. It's the next
best thing if you can't have garbage collection.
I don't have a fundamental objection to ref-counting. It's used
extensively in COM under Windows, and I've used it in a variety of
other contexts as well. The problem is ref-counting without well-
defined rules as to when you've been granted an implicit owner count
and when you haven't (manual release versus autorelease). Actually,
COM has similar issues (some methods return an object you need to
AddRef() in order to keep, others require that you explicitly Release
() if you don't want to keep it), but that doesn't mean there's
something wrong with ref-counting.
Basically, it seems to me that auto-release pools are just a "poor
man's garbage collection", and introduce ambiguity as to if and when
code needs to explicitly release objects. While it's not the auto-
release pools per se that introduce the ambiguity in the ref-counting
paradigm, they encourage the variable behavior (some object
instantiation mechanisms auto-release, others do not).
What has Apple said (publicly, of course) with respect to the
future of Carbon, and is someone (me, for example) going to regret
starting down the path of learning to use the Carbon API now, only
to find that Apple is going to deprecate it some time in the near
future?
It does seem like a nice summary of some messages on this mailing
list. But it doesn't really answer my question. Thank you for
providing the link anyway.
Pete
_______________________________________________
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
