• 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: Super's Super?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Super's Super?


  • Subject: Re: Super's Super?
  • From: Chris Purcell <email@hidden>
  • Date: Sun, 12 May 2002 10:46:03 +0100

If you don't have access to the source of either class, you can always just add a category to Parent, as in:

@interface Grandparent // This is all you can see of Grandparent
- problemFunction;
@end

@implementation Parent (myCategory)
- callGrandparentFunction // This will always call Grandparent's implementation of problemFunction
{ [super problemFunction]; }
@end

@implementation Child
- problemFunction // This can now call the desired implementation
{ [super callGrandparentFunction]; }
@end

Kritter out

Yep, I think Charles has the right idea. To be a little more concrete, I
think your classes should look like:

*snip*

Maybe your class should be the subclass of the super-super class
instead of its current superclass?


Unfortunately, no. My first thought was exactly the same - perhaps the
design was wrong.. but in this case, the class is most definitely
appropriately a child of its superclass, there's just this one method
where the behavior needs to be totally different, but I still need the
functionality that the grandparent object (a non-concrete class that
is the root of my framework's heirarchy) provides. =(

Hmm, maybe you could make the grandparent's method look like this:

- (someType)someMethodWithArgument:(someOtherType)someArgument {
return [someOtherMethodWithArgument:someArgument];
}

The parent class could override this, and the grandchild class could
override that and call someOtherMethodWithArgument: .

Just a thought, don't know how good it is...

Charles
_______________________________________________
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.

  • Prev by Date: NSProgressIndicator -setFrameOrigin visual updating anomaly
  • Next by Date: Re: NSProgressIndicator -setFrameOrigin visual updating anomaly
  • Previous by thread: Re: Super's Super?
  • Next by thread: draw pdf crash with certain pdfs
  • Index(es):
    • Date
    • Thread