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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to