RE: Getting a variable from another class
RE: Getting a variable from another class
- Subject: RE: Getting a variable from another class
- From: "Kenny Millar" <email@hidden>
- Date: Wed, 15 Mar 2006 10:24:43 -0000
- Organization: Kenny Millar
That book is a total waste of space. I do not know why it is ADC
Recommended.
For a much better look at Cocoa/Objective-c, get a hold of Aaron Hillegass
book, 'Cocoa programming for Mac OS X' - it is a great book.
-kenny
-----Original Message-----
From: cocoa-dev-bounces+kennymillar=email@hidden
[mailto:cocoa-dev-bounces+kennymillar=email@hidden] On Behalf Of
Matthew Egan
Sent: 15 March 2006 10:10
To: email@hidden
Cc: email@hidden
Subject: Re: Getting a variable from another class
Hi Wade
Thanks for the info. I will try and implement this into my code.
As for books - I have read Learning Cocoa with Objective-C but that
seems to be a basic overview of Cocoa to get an experienced Obj-c
programmer up-to-speed. I have gone through the book again and any
examples of accessor methods is sort of glossed over. All of the
example code involves a single implementation file. So it's onto book
TWO - Cocoa in a Nutshell :-(
And no - I'm not going to the next aisle - "C++ and other static
typed languages" - Cocoa will do me fine thanks ;-)
Matt Egan
On 14/03/2006, at 10:22 PM, email@hidden wrote:
>> You can declare public ivars using the @public keyword like this
>> (typed in mail):
>>
>> @interface MyObject {
>> NSString *name; //This variable is protected.
>>
>> @public
>> NSString *publicName; //This variable is public, and can
be
>> accessed directly by anyone
>> }
>> @end
>>
>> You can also use the @defs() directive in order to access private/
>> protected ivars but it is not recommended in most cases.
>
> This is not a good approach in any case.... you really shouldn't
> try to access another class's instance variables directly....
> @public really should be thrown out. :P
>
> What you want to do is declare them as @private or @protected as
> normal, and provide accessor methods to access them. For example,
> to subvert the example above:
>
>> @interface MyObject {
>> @protected
>> NSString *_name; //This variable is protected.
>> }
>>
>> - (void)setName:(NSString*)name;
>> - (NSString*)name;
>>
>> @end
>>
>> @implementation MyObject {
>>
>> - (void)setName:(NSString*)name {
>> if (name != _name) {
>> [_name release];
>> _name = [name copy];
>> }
>> }
>>
>> - (NSString*)name {
>> return [[_name copy] autorelease];
>> }
>>
>> @end
>
> Basic things like this are well covered in all the Cocoa books out
> there. I'd recommend you pick up at least one of them and work
> through them.
>
> Note that it's a good idea to have accessors in any class which has
> even the most remote possibility of being subclassed. If that
> possibility exists, all your class's methods should use those
> getters in preference to accessing the instance variables
> directly. Thus, subclasses can override those getters if they
> like. Otherwise, your subclasses may be limited by those direct
> accesses and whatever model you have for those instance variables.
> If they're declared @private, your subclass may not be able to
> modify them at all, defeating the purpose of inheritance in the
> language. Worst of all, it won't stop stubborn people getting
> control - they'll just use very nasty methods to do so.
>
> And if you're worried about frequent use of getter methods - e.g.
> as regards performance - you'll be wanting the next aisle, "C++ and
> other static typed languages". :P
_______________________________________________
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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