On Jul 11, 2012, at 1:45 PM, Motti Shneor wrote: > Wow, and thanks, everyone. BTW, what does "OP" stand for? (obviously, its > me...)
OP = original poster > Of what I read from everyone, and after examining the suggested code from > Jens Alfke, I think I'm inclined to something simpler, hinted by Keary > Suska. Could you spare a few more words on the "undefinedKey" override? This is part of the NSKeyValueCoding protocol http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html. > I'd like to avoid dynamic auto-generation of methods at runtime. I can't see > why this is needed --- ALL my getters and setters will look exactly the same. Actually, generation of methods is exactly what you want, because all of your getters and setters will look exactly the same. The question arises as to how they should be generated. 1. Copy-Paste: bad idea. lots of code, really slow, easy to mess up, etc 2. At Runtime: arguably the most flexible approach, but also the most complex. 3. At compiletime: easy to understand. Define a macro that you would use instead of "@synthesize" or "@dynamic". Something like this: #define SYNTHESIZE(_property, _setter) \ - (void) _setter (id)newValue { \ [internalMutableDict setObject:newValue forKey:@"" ##_property]; \ } \ - (id) _property { \ return [internalMutableDict objectForKey:@"" ##_property]; \ } And then you'd do: @implementation Foo SYNTHESIZE(firstName, setFirstName:) SYNTHESIZE(lastName, setLastName:) SYNTHESIZE(age, setAge:) @end And so on. (Warning, typed in a Mail window and not tested) Dave > > We have dozens such "data classes", and I hate to copy-paste zillions of > exactly-the-same implementations by hand. For every property (e.g. > "firstName") I would need to to write > > - (NSString *)firstName { > return [internalMutableDict valueForKey:firstName]; > } > - (void) setFirstName :(NSString *)firstName { > [internalMutableDict setValue:firstName forKey:@"firstName"]; > } > > Isn't writing 1000 such implementations error-prone? call for automation of > some kind? > > The reason we insist on dot-notation for accessing these objects, is that the > code which does this, is written in C++ or C style, using structs and dot > notation. That code could compile with no change against C++ data objects (in > Windows) or against my Propery-based data objects for Mac. > > So... It's not that we're anti-CD, on the contrary.... only this is a big > project with lot's of legacy shared code imposed on the system, to say > nothing of legacy thinking and "shared thoughts" by management. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
