On 21 May '08, at 12:37 PM, Johnny Lundy wrote:

I submit that any experienced programmer looking up and turning to a page entitled "NSArray Class Reference" would "expect" that a behavior of the class that results in one's created object being deallocated out from under him would be documented in such a "Reference."

Not if it's due to a generic behavior of all objects. That would create endless verbosity. For the same reason, you'll note that while every class responds to -retain and -release, those methods are not documented separately in every class.

I've been reading this documentation for six years. This incompleteness has bugged me the whole time. Conversely, the docs on AppleScript Studio and Carbon do not suffer from this problem - look up a Carbon C function and you're pretty much good to go.

Carbon isn't a framework; it's pretty "flat" in that every API mostly re-invents the same wheels without building on others (with the exception of low-level basics like the Memory Manager.) In a framework, like Cocoa, there really are fundamentals that everything else builds on, just as all the other classes inherit from NSObject.

Well, that makes the point that some of us are trying to make. It may be "expected" by you, or even by Apple, but that is not relevant. What is relevant is what the person trying to USE the documentation "expects."

You can only take that "the customer is always right" argument so far, and that point is about a half mile back from where you've just ended up. If you want to learn stuff in any order you want and get instant support whenever you get stuck, you're going to need to pay a mentor/ consultant to do that for you. No single source of documentation is going to let every person follow their individual whims that way. The docs are organized in a way that tries to work for the majority of readers, and if you're not going to pay by the nose for personalized instruction, you'd do best to go with the way the docs work.

—Jens

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to