[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSAttributeString source code....

From: Lars Sonchocky-Helldorf
Subject: Re: NSAttributeString source code....
Date: Tue, 6 Jun 2006 22:07:16 +0200

Am 06.06.2006 um 17:26 schrieb Richard Frith-Macdonald:

On 2 Jun 2006, at 10:24, Lloyd Dupont wrote:

In NSAttributedString I found the following code (snippets)
======= NSAttributedString.m (snippets) ==============

static SEL getSel;

@implementation NSAttributedString

+ (void) initialize
 if (self == [NSAttributedString class])
     getSel = @selector(attributesAtIndex:effectiveRange:);

- (NSDictionary*) attributesAtIndex: (unsigned int)index
      longestEffectiveRange: (NSRange*)aRange
      inRange: (NSRange)rangeLimit
 NSDictionary *attrDictionary;
 IMP  getImp;

 getImp = [self methodForSelector: getSel];
 attrDictionary = (*getImp)(self, getSel, index, aRange);
 return attrDictionary;


Now I wonder.....
Why in Hell write that?

I mean what's wrong with:
attrDictionary = [self attributesAtIndex: index effectiveRange: aRange]
Why replace it by:
 static SEL getSel;
 getSel = @selector(attributesAtIndex:effectiveRange:);
 getImp = [self methodForSelector: getSel];
 attrDictionary = (*getImp)(self, getSel, index, aRange);

Yes, why????
why GNUstep code work so hard at being so obscure???

Well if the code was as listed above it would be really stupid ... but of course it's not.

In fact the call to (*getImp)(self, getSel, index, aRange) is done inside a loop and might get called a lot of times. Where the attributed string is actually a large document that can make a significant difference to performance by removing method lookup overheads.

wouldn't some comments in the code at such places make things a lot clearer? A simple

// caching for perfomance

would have avoided some confusion and would definitely help newcomers to get easier access to GNUstep coding. Otherwise it looks like voodoo and confuses people. Some short comments on obscure place sometimes help a lot. You don't need to write novels. Easy access to the code is important to involve more developers.

Most (maybe all) cases where the code caches method implementations are for situations where it's been tuned for performance because the method call overheads were becoming an issue. By the nature of things this needs to be done mostly in heavily used parts of the base library ... and the fact that it's done there does *NOT* in any way imply that it's sensible to do that sort of thing routinely in applications (or other libraries). That is to say, the base library source is a good example of how to write a base/foundation library, not a good example of how to write general code. I almost never cache method implementations in my appllication code.

regards, Lars

reply via email to

[Prev in Thread] Current Thread [Next in Thread]