Re: Problem with NSMutableDictionary
Re: Problem with NSMutableDictionary
- Subject: Re: Problem with NSMutableDictionary
- From: mmalc crawford <email@hidden>
- Date: Sun, 19 Aug 2007 14:05:01 -0700
On Aug 19, 2007, at 11:36 AM, Peter Duniho wrote:
On Aug 19, 2007, at 10:54 AM, mmalc crawford wrote:
On Aug 19, 2007, at 10:27 AM, Peter Duniho wrote:
(Hint: it seems that those who have reached the point where they
no longer need to consult the reference for every other line of
code they write don't see a need to improve the reference :) ).
Simply using a smiley doesn't mean that the comment isn't obnoxious.
Um. Okay. How's this: I find that the people who are already
fluent in Objective-C and Cocoa are generally disdainful and
dismissive of the concerns and comments of those of us trying to
learn it. Frankly, the elitist, arrogant attitudes I've run into
while trying to learn how to write Mac software in today's
environment are incredibly off-putting and make me question whether
I really even want to bother trying to get back into the Mac
programming world after a 20-year hiatus.
I suggest you read <http://catb.org/~esr/faqs/smart-questions.html> --
this issue is covered in the Introduction.
I haven't been the target of this very much. Frankly, I've seen
enough directed at other people that I do my best to avoid posting
any questions, and have been able to stay out of the line of fire
for the most part. But when I see people trying to defend the
current state of the Mac programming reference, I just cannot stay
silent. It is in too much need of improvement for me to accept any
serious claim that the current documentation is adequate.
There are many valid criticisms that may be made of the documentation;
it is more useful if they are made in a constructive fashion.
The API reference is intended solely to be a "dictionary", not an
encyclopaedia.
Well, I haven't seen any official comments regarding what it's
"intended" to be. However, if your claim is true, then the intent
is wrong. The API reference _should_ be an encyclopedia. Guides
are for covering high-level, general topics and providing basic
tutorials to get one started. The API reference should, on the
other hand, leave no detail out. It should be a _REFERENCE_, with a
complete, comprehensive description of every aspect of the API.
You're describing what I mean by dictionary. An encyclopaedia,
however, typically provides additional material that goes beyond the
scope of the term being defined. The various Guides are the documents
that bring the API together, sometimes focussed on a narrow topic
(such as the String Programming Guide <http://developer.apple.com/documentation/Cocoa/Conceptual/Strings/index.html
>), other times casting a wider net (e.g. the Performance Guide <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaPerformance/index.html
>).
Typically, conceptual documentation and tutorials are listed in the
"Companion guide" field in the API reference.
The "guide" sections of the reference are not comprehensive either.
In fact, most of the time they gloss right over a number of
important aspects. There are exceptions, but on the whole the
"guides" are not in any way a replacement for the API reference, nor
do they succeed in filling in the details left out of the API
reference.
As noted previously, the Guides etc. are not intended replacement for
the API reference.
But in addition to all that, they simply aren't structured in a way
that allows for easy reference for a specific issue. Even if the
guides were comprehensive, if one cannot easily find the information
that's important, that's of no use.
Using the phrase "autorelease behaviour" suggests you still don't
fully understand memory management.
There's a good example of what I mean about the arrogance and
dismissiveness of the experts right there.
It is neither arrogant nor dismissive, it's a simple straightforward
assessment based on a decade and a half of watching others learn about
the technology...
How is it that from two simple words, you have come to the
conclusion that I don't fully understand memory management? Even
ignoring for a moment that I find flawed your semantic argument that
"ownership" is somehow completely independent of "whether or not
something is autoreleased",
... QED. I didn't write that they're completely independent, however
autorelease is an implementation detail of the ownership policy:
"You take ownership of an object if you create it using a method whose
name begins with “alloc” or “new” or contains “copy” (for example,
alloc, newObject, or mutableCopy), or if you send it a retain message."
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
>
Consider a concrete example. Which of these string is autoreleased,
and how does that affect *ownership*? Which of these strings do you
own?
NSString *string1 = @"a string";
NSString *string2 = [NSString stringWithString:@"a string"];
NSString *string3 = [aPerson firstName];
NSString *string4 = [NSString stringWithFormat:@"aPerson firstName:
%@", string3];
NSString *string5 = [string4 copy];
Answer/discussion:
The only string you *own* is string5, but it's actually autoreleased
because it was created as string4 using stringWithFormat:. string3
*and* string2 may or may not be autoreleased -- whether they are or
not is irrelevant to ownership (you don't own them).
Apple needs developers. They cannot afford to say "oh, it's too
hard to do that".
And again, it's not a question of "it's too hard", it's a question of
where would time best be spent. Is it better to spend a month or two
of writer effort adding boilerplate text to every method definition to
explain something that should be readily apparent by simple
application of a fundamental rule (does the method name begin with
“alloc” or “new” or contain “copy”), or is it better to write new
guides and tutorials or augment existing ones?
mmalc
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden