Re: Keys of the kingdom - THANKS!
Re: Keys of the kingdom - THANKS!
- Subject: Re: Keys of the kingdom - THANKS!
- From: Boyd Collier <email@hidden>
- Date: Sat, 22 Apr 2006 16:45:11 -0700
Ah! I get it! Thanks, Ryan.
Boyd
On Apr 22, 2006, at 3:58 PM, Ryan Britton wrote:
Something like this:
file.h
------------------------
extern const NSString *MSFileBackupDate;
file.m
---------------------------------------
const NSString *MSFileBackupDate = @"MSFileBackupDate";
Everything that imports file.h will be able to access the string
MSFileBackupDate though the actual contents of that string are
completely arbitrary. Everyone using the constant gets to refer to
it by that name and ignore what the real value is.
On Apr 22, 2006, at 3:49 PM, Boyd Collier wrote:
I had the same question as Kevin, but my c is a bit rusty. Ondra,
could you be
more specific re using extern const in this context?
Thanks, Boyd
On Apr 19, 2006, at 2:14 PM, Ondra Cada wrote:
Kevin,
On 19.4.2006, at 23:10, Kevin Bracey wrote:
How do you manage these 3 different types of Keys? (and any others)
Depends. API stuff I tend to extern const; the internal one is
either #defined, or used directly.
( I notice the Cocoa headers use extern const which seems like
4x the work and I'm not sure why they do it like this?)
Just 2x the work, not 4x :)
It's the cleanest way possible, I guess (not the most flexible
one, but that's another story).
For the Localised Strings and UserDefaults where should I define
these keys?
In my personal opinion, depends on usage. API stuff (defaults
sometimes, localised strings hardly ever) goes to extern const,
*very rarely* (if the flexibility is needed) to a class method
which returns the thing. Non-API oft-used stuff I #define. Non-
API once-or-twice used stuff I just write and that's that :)
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40sunstroke.sdsu.edu
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40sunstroke.sdsu.edu
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden