Only now these two implementations are missing:
-(NSUInteger)indexOfKey:(id)anObject;
-(id)keyAtIndex:(NSUInteger)index;

Something like this:

#import

@interface SortedDictionary : NSObject
{
NSMutableArray *underlyingArray;
NSMutableDictionary *underlyingDictionary;
}
@property(nonatomic, retain) NSMutableArray *underlyingArray;
@property(nonatomic, retain) NSMutableDictionary *underlyingDictionary;

#pragma mark NSDictionary methods
-(id)objectForKey:(id)aKey;
-(id)valueForKey:(NSString *)key;
-(NSUInteger)count;
-(NSArray *)allKeys;
-(NSArray *)allValues;

#pragma mark NSMutableDictionary methods
-(void)setObject:(id)anObject forKey:(id)aKey;
-(void)setValue:(id)value forKey:(NSString *)key;
-(void)removeObjectForKey:(id)aKey;
-(void)removeAllObjects;

#pragma mark Customized NSArray methods
-(NSUInteger)indexOfKey:(id)anObject;
-(id)keyAtIndex:(NSUInteger)index;

#pragma mark custom methods
-(void)addObject:(id)anObject forKey:(id)aKey;
-(void)addValue:(id)value forKey:(NSString *)key;

@end

Could you also share to .h file?

Thanks!

Leon

As far as whether a person should carry around a one page license for their personal libraries, especially if they work for more than one company or do consulting? The answer is: YES. Yes, they should, because that’s the sensible way of avoiding having to write MySortedDictionary or MyBufferClassWhichActuallyWorks every single time that the problem comes up again.

I’ll just be the old, grumpy programmer complaining about kids these days who get so spoiled by having standard libraries that do everything for them that the forget what it was like to do real programming, and go back to keeping the neighbor kids off of my lawn.

OR … you have to write (and maintain) an entire library just to contain this, so that you only have one copy of hte source.

But … now what happens when you update the version? Xcode-for-iPhone is extremely weak at managing library versioning (it works OK on OS X, but a lot of the versioning stuff seems to be disabled for iPhone). You have to regression test against every project you ever made.

And what about working on different projects for different companies? Are you going to write a one-page license and give it to each client you worked for? (obviously, you don’t *have* to – but not doing so tends to revert to the “many copies lying around all running different versions”).

Basically: for any fundamental classes, if they’re not inside a standard library, it is a massive pain to deal with them in the long term. This is one of the massive wins that Java brought, and has since been adopted by most new languages. It doesn’t seem that big a deal at first, but once you’re maintaining apps on a regular basis, suddenly it IS a big deal

(compare this to e.g. PHP, which is stuck with non-standard standard libraries – a horrific mess – where most people end up using the 3rd party libs anyway. Development is slower and more error-prone whenever you do anything in PHP that works with a library, because it’s so easy to not be aware that App X is using a version of Lib Y that you’ve never even seen before).

I’m sorry, I’m probably reacting to what’s intended as a dramatic statement, but what part of XCode development makes the reuse of a developer’s personal code library difficult?

It seems to be a bit like complaining that Extensions are useless because the added methods aren’t automatically visible to all applications.