Frameworks, categories and shared namespace

[Adam R. Maxwell]

On Jun 8, 2008, at 7:54 AM, Christiaan Hofman wrote:

> On 8 Jun 2008, at 4:50 PM, Uli Kusterer wrote:
>
>> Am 07.06.2008 um 08:25 schrieb Adam R. Maxwell:
>>> If you're adding a lot of methods to an Apple-supplied class, I  
>>> think it's preferable to use a subclass, framework or not (but  
>>> that doesn't work with some objects, e.g. singletons).
>>
>>
>> It also doesn't help when you're not the one creating the object,  
>> e.g. you get it from a system library.
>>
>> Cheers,
>> -- Uli Kusterer
>> "The Witnesses of TeachText are everywhere..."
>> http://www.zathras.de
>
> That's basically the situation I'm asking about. When the class is  
> defined in the framework I don't really care.

Not sure what Christiaan's thinking of in particular, but here's a  
concrete example based on my interpretation of his question.

Sparkle 1.5b1 (popular application updating framework) includes  
various categories, including one on NSBundle:

- (NSString *)name;
- (NSString *)version;
- (NSString *)displayVersion;
- (NSImage *)icon;
- (BOOL)isRunningFromDiskImage;
- (NSArray *)systemProfile;
- (NSString *)publicDSAKey;

Any of these could be added by Apple in some future version of OS X,  
and Sparkle's implementation will most likely override Foundation's  
implementation.  Worse, some of these may exist now as private methods  
with different semantics.

If I write a category like this and compile it into my app, it's my  
own fault if it breaks; if you're writing a framework that other  
people will use, they may not even realize that all of these  
categories exist.  Suppose that in a future release of OS X, Apple  
implements -[NSBundle systemProfile] to return an XML string; what are  
the implications for all the clients of the Sparkle framework?  Worse,  
if Apple implements it in a category on NSBundle, it's not even clear  
whose implementation will win out.

So if I understand correctly, Christiaan is asking what the best  
practice is in this case for framework developers.  (And I'm not  
singling out Sparkle...it's just a convenient example that was brought  
to mind recently).

-- 
adam