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). > > <ESObjectWithPropertiesAndIvars.diff> > > 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). Cheers, Evan
