ESObjectWithProperties using ivars
Evan Schoenberg, M.D.
evan.s at dreskin.net
Wed Jun 2 20:54:57 UTC 2010
On May 20, 2010, at 5:36 PM, Thijs Alkemade wrote:
> Hello Adium-devs,
> After following development loosely for a while, I have more free time now, so I'm trying to get into Adium development myself. :)
> Little bit of background first: while I was looking through the code of AIChats I stumbled upon the ESObjectWithProperties class. I couldn't understand how what it did could not be done with things like bindings or notifications so I asked in #adium-devl.
> Catfish_Man explained to me that it was necessary for coalescing notifications, and he told he he had once tried to get it to work with ivars instead of the slow NSDictionary, but couldn't get it working. I thought this could be a fun thing to work on myself, as I wasn't very familiar with the inner workings of the Objective-C runtime. I got it to work, including direct access to ints, NSIntegers and BOOLs using the already existing -intValueForKey, -integerValueForKey and -boolValueForKey. I've attached the diff of ESObjectWithProperties.m. GCC will show some warnings, but those are unavoidable (accessing primitive fields directly looks a bit awkward).
> It will first look for an ivar with the name of the key, and if that isn't found, falls back to the dictionary. This alone will not do much, but there is a patch I'm still working on to replace all of the (nearly) always-set properties with ivars, but that is getting huge (as most keys for properties contain spaces and aren't in camelCase).
> Now as the core functionality is working, and only the large and boring task of renaming everything remains, I wanted to ask all the developers: do you agree this is a good thing to use? The advantages are: faster lookup and more efficient storage of properties, more clearly structured code (AIListContact has 18(!) properties that for most objects get set, but you can't find those easily in the code). There is however a rather nasty disadvantage: all ivars of ESObjectWithProperties's are exposed, and can be modified or read without invoking any of the setter/getter-functions. This may seem harmless, but could be rather bad for encapsulation or protecting certain properties.
> Any feedback would be appreciated. :)
> Thijs Alkemade (xnyhps on #adium/sphynx on trac)
It's a neat idea, and I'm glad to see you working on something that excites you :)
I do hate to see us making changes that require warnings... is it unavoidable that this throw warnings, or a work-in-progress sort of issue?
I'm not worried about exposing the ivars; a benign plugin will be using them properly, and a malicious plugin could get access to the same data via some trickery anyways (e.g. poseAsClass and knowledge of our headers).
More information about the devel