• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: class cluster making: easy/lazy way to keep counterpart methods in sync?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: class cluster making: easy/lazy way to keep counterpart methods in sync?


  • Subject: Re: class cluster making: easy/lazy way to keep counterpart methods in sync?
  • From: "M. Uli Kusterer" <email@hidden>
  • Date: Sun, 22 Feb 2004 00:00:11 +0100

At 22:13 Uhr +0000 21.02.2004, Ben Dougall wrote:
similar, not identical methods. like the NSNumber class that's on the usual class cluster apple documentation page -- a class cluster because the requirements for storage varies. and the ivars go in the subclasses as do the methods that access them.

You can still give them all the same base class. You just have to factor the methods the right way.

Just split the bigger method into many smaller ones. E.g. if you had a DoSomethingNTimes class, and you wanted to have different variants depending on whether your counter is a float or an int or a long long, you could do something like:

@implementation DoSomethingNTimes

-(void) doItNTimes
{
for( [self doLoopInit]; [self doLoopCondition]; [self doLoopIncrement] )
[self doLoopAction];
}

@end

@interface DoSomethingIntNTimes : DoSomethingNTimes
{
int myCounter;
int myMaxIterations;
int myLoopStepWidth;
}


@end

@implementation DoSomethingIntNTimes

-(void) doLoopInit
{
myCounter = 0;
}

-(BOOL) doLoopCondition
{
return (myCounter < myMaxIterations);
}

-(void) doLoopIncrement
{
myCounter += myLoopStepWidth;
}

-(void) doLoopAction
{
[target setIntValue: myCounter];
[target performSelector: action];
}

@end


You get the idea... the algorithm itself stays the same, and you factor out anything that accesses the member variables or operats on them.

If that isn't applicable to your case (e.g. if your loop condition was very complicated and did lots of calculations with myCounter), you could alternatively use #define to declare a Macro that does the beef, then just use that macro in each of your subclasses:


#define LOOP_INIT(n) ((n) = 0)
#define LOOP_CONDITION(n,o) ((n) < (o))
#define LOOP_INCREMENT(n) ((n)++)

-(void) doItNTimes
{
for( LOOP_INIT(myCounter); LOOP_CONDITION(myCounter, myMaxIterations); LOOP_INCREMENT(myCounter) )
[self doLoopAction];
}

yadda, yadda, yadda. But if you can, use the former. The latter becomes very unreadable when you have multi-line expressions (so if you can, use a new macro for each line) and can also be harder to debug because the debugger doesn't show the C code the macro compiles to.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: class cluster making: easy/lazy way to keep counterpart methods in sync? (From: Ben Dougall <email@hidden>)

  • Prev by Date: Re: class cluster making: easy/lazy way to keep counterpart methods in sync?
  • Next by Date: Re: Zlib compression
  • Previous by thread: Re: class cluster making: easy/lazy way to keep counterpart methods in sync?
  • Next by thread: Re: class cluster making: easy/lazy way to keep counterpart methods in sync?
  • Index(es):
    • Date
    • Thread