• 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: best practices for globals/identifiers in a Cocoa app
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: best practices for globals/identifiers in a Cocoa app


  • Subject: Re: best practices for globals/identifiers in a Cocoa app
  • From: John Clayton <email@hidden>
  • Date: Sun, 09 Nov 2003 20:50:26 -0500

Wow, that's cool. So a .m file with no implementation is fine. That makes sense ... now. Thanks, Alistair.

Oh also, would you also say that the general approach of storing strings/keys in extern'd variables is the right way? I know some people use macros, and I know extern'd variables like this need to be careful of name collisions. But, the former approach seems to be more in keeping with the Obj-C approach. Would you agree?

john



On Nov 9, 2003, at 8:11 PM, Alastair Houghton wrote:

On 10 Nov 2003, at 00:50, John Clayton wrote:

Hi,

When using strings and such as identifiers, especially when tying into
interface elements like a table column name, or in user defaults as
keys, etc., I have been in the practice of doing something like this:

MyClass.h

extern NSString * myIdent ;

MyClass.m

NSString* myIdent = @"the_name_of_something";

and then using the variable in place of the actual string.

This works fine, except that the amount of these things is growing
rather large and keeping them in my app delegate like I have been
doing seems cumbersome. Is there an acceptable way to keep them in a
separate file?

Just create another .m file in your project, and put them in there.
You could call it "strings.m" or something similar. This is exactly
the same thing you might do in a C program in similar circumstances.

As for which header they live in, you can leave them where they are at
the moment, or you could move them to a separate header... it really
doesn't matter. (Remember, there is no link between header file name
and implementation file name other than the one you have in your
head... the compiler does not care what you call your files [as long as
they have extensions it recognises].)

Kind regards,

Alastair.

[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.
_______________________________________________
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.

  • Follow-Ups:
    • Re: best practices for globals/identifiers in a Cocoa app
      • From: Alastair Houghton <email@hidden>
References: 
 >best practices for globals/identifiers in a Cocoa app (From: John Clayton <email@hidden>)
 >Re: best practices for globals/identifiers in a Cocoa app (From: Alastair Houghton <email@hidden>)

  • Prev by Date: NSView subclass bindings? NSTextView?
  • Next by Date: Re: NSArrayController population
  • Previous by thread: Re: best practices for globals/identifiers in a Cocoa app
  • Next by thread: Re: best practices for globals/identifiers in a Cocoa app
  • Index(es):
    • Date
    • Thread