• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Addressbook api
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Addressbook api


  • Subject: Re: Addressbook api
  • From: Ondra Cada <email@hidden>
  • Date: Fri, 6 Sep 2002 19:11:36 +0200

On Friday, September 6, 2002, at 06:05 , Bill Cheeseman wrote:

on 02-09-06 10:52 AM, Ondra Cada at email@hidden wrote:

(should be a NULL, I believe, at least according to the documentation).

No. These are _objects_, and therefore nil is what you want. NULLs are for
pointers (you use it eg. in scanner methods, for things like NSString**)
.

And NULL for SEL parameters where allowed, as in sheet functions.

Sure. Since SEL has no "own NULL" like id or Class do, you have to use NULL (or 0 ;)

So, you are saying the documentation for NSDictionary's
+dictionaryWithObjectsAndKeys: is just wrong -- or carelessly worded?

From the class reference document: "dictionaryWithObjectsAndKeys: takes a
variable number of arguments: a null-terminated list of alternating objects
and keys. If any key is nil, an NSInvalidArgumentException is raised."

I note that the "null" in "null-terminated list" in the quote is lower-case,
so perhaps not meant to refer to NULL.

Yeah, I think so. Definitely, all dictionaryWithObjectsAndKeys: arguments are ids, and thus for cleanness you should use nil.

Nevertheless, the probability NULL and nil values might actually differ is next to zero, so the debate is kind of academic ;) In practice, using "NULL", "nil", and "Nil" (and even "0"!) is completely equal anywhere; the only difference is in the code readability, where

0 means "a number should be here, and it's a zero"
NULL means "a generic pointer should be here, but it is not supplied"
nil means "an object should be here, but it is not supplied"
Nil means "a class should be here, but it is not supplied"

Note that these scopes do overlap: class is an object too, any object is a pointer too. Therefore, you should contentedly use nil if either instance or class might be used, or NULL if any pointer including an object reference can be used, like in:

[array sortedArrayUsingFunction:foo context:&whatever];
[array sortedArrayUsingFunction:foo context:@"Or an object (beware memory management)"];
[array sortedArrayUsingFunction:foo context:[NSArray class]];
[array sortedArrayUsingFunction:foo context:NULL]; // no "nil" or "Nil" here

This rule though is very very soft, and it is reasonable to bend it often.
Presumably you have a piece of code where the context: argument *always* contains a string; if so, it would be better in those places where the context is not needed to use "nil" than "NULL" -- since, in such conditions you omitted rather an object than a generic pointer.
---
Ondra Cada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: Addressbook api (From: Bill Cheeseman <email@hidden>)

  • Prev by Date: Re: Get parent process (Carbon question)
  • Next by Date: Re: Addressbook api
  • Previous by thread: Re: Addressbook api
  • Next by thread: Re: Addressbook api
  • Index(es):
    • Date
    • Thread