Re: The "correct" approach? Question about creating an NSMutableDictionary instance.
Re: The "correct" approach? Question about creating an NSMutableDictionary instance.
- Subject: Re: The "correct" approach? Question about creating an NSMutableDictionary instance.
- From: Michael de Haan <email@hidden>
- Date: Thu, 22 Oct 2009 19:15:38 -0700
Graham...firstly thank you. I certainly did not try and make it
harder...I **thought** I was making it easier to present what I
thought was the crux of the issue. :-) So much for that thought!
On Oct 22, 2009, at 6:47 PM, Graham Cox wrote:
On 23/10/2009, at 12:27 PM, Michael de Haan wrote:
{
self = ....snip...usual code
NSString * _name = @"John Doe";
NSString * _city
....snip...other string properties
OK, these are NOT "properties". They are simply local variables.
Point taken. My loose syntax did not correctly convey what I thought
was happening.
_record = [ NSMutableDictionary dictionaryWithObjectsAndKeys:
_name, MDHNameKey,
....snip...
nil;
}
return self;
}
As I learnt, self returns an empty object. ( If I understand it
correctly, the local variables _name etc are no longer in scope
once self is returned.)
This should not return an empty object, but it should return one
having the ivar _record. One question is whether you're using
garbage collection or not, because if not, then _record is shortly
going to get autoreleased, leading to a stale reference and almost
certain disaster (unless you've also snipped out vital memory
management calls as well as the closing square bracket).
Again, my lack of articulation/understanding. What I **meant** was
that I could see an object created (in the debugger) in Record's init
method. If I displayed this object in a log statement, it correctly
wrote the **local variables** to the console :-) If I did the same
in the calling method, the object ( same value in the debugger) now
did **not** write those local variables to the console. I incorrectly
labeled this as "empty". To answer about GC, No. You, I think much
more succinctly identified the issue that I was trying to convey.
If you are truly getting an empty object, then you'll have to show
all the code you've snipped to be able to say why.
Second approach.
Record Object with 4 ivars viz
_name
_city etc etc
Self now returns an object whose attributes are now, in the calling
method ( the "AddRecord") used to create the NSMutableDictionary
object and added "model" array, and the table populates as expected.
OK, read this about twenty times now and still have no clear idea
what you mean. What mutable dictionary? Having done it this way, you
no longer need one as far as I can see.
In words, ( also tried to do it diagrammatically...see below)
In the dataSource object ( which in this case is a doc subclass) I
have declared an array as an Ivar ( I called it "_record_list"). To
this array, I added the object created in the AddRecord method of the
doc object. That object is the NSMutableDictionary Object, (which uses
the returned object from the Record Class init method).
So, ( and I hope this comes out)
So ---> AddRecord (in doc class) ---> init ( Record Class)
|
|
|
↓
Record_object ( with 4 values ) ---> Returned to AddRecord Method
-------> Used to create NSMutableDictionary Object ---------> Added to
Doc Array----------> Used by TableView as source of display in
tableView.
May I ask if this is the correct approach? ...or should one still
try and aim to **return** a dictionary object to the calling method?
Personally I'd say your second approach is more usual. You *could*
store your properties in a dictionary - this storage is an
implementation detail of your record class. However it's usually
easier just to have a separate ivar for each one, which is how the
KVC system is typically implemented. If you exposed your 'record'
property as a property in itself, you could access individual
properties using a keypath such as yourObject.record.someKey, but
typically you'd just want yourObject.someKey so that the
implementation of the property storage is not exposed.
Thanks Graham....your input is always very valuable in my quest
through Hillegass.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden