• 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: Category conflicts with Tiger
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Category conflicts with Tiger


  • Subject: Re: Category conflicts with Tiger
  • From: Daniel Jalkut <email@hidden>
  • Date: Sun, 8 May 2005 01:43:37 -0700

It sounds like the moral of the story is to always name your category methods on system classes with purposely obtuse names. Even if Apple adds a "copy:" method to some class in the future, it seems like it would be risky to assume that it behave the same and has the same side effects as the one we implement today.

D

On May 7, 2005, at 9:36 PM, Greg Parker wrote:

David Sinclair wrote:

One such is a NSImageView category that implements -cut:, -copy:,
-paste:, and -delete:. I see that NSImageView now implements those
natively. I can't simply rename my editions, since then they wouldn't
be used, and can't remove them, as then those functions wouldn't work
when running under Panther. What is the best way to resolve this
conflict?



Here's one way to do it, using a bit of lower-level Objective-C runtime hacking. Write your implementation as a C function, and add a category with a +load method but nothing else. Then, when the category gets loaded, check whether the class already has an implementation of the method you want. If not, add your implementation to the class.

This example adds a -copy method to NSObject. Multiple methods
and class methods are left as an exercise for the reader. (The
already-loaded check works around a Tiger bug where a category
+load method may be called twice if its class has no class methods.)

#import <Foundation/Foundation.h>
#import <objc/objc-class.h>

@implementation NSObject(MyCopy)

static void copy(id self, SEL _cmd)
{
    // ... custom implementation of -copy ...
}

+ (void)load
{
    static BOOL loaded = NO;
    if (loaded) return;
    loaded = YES;

    if (! [self instancesRespondToSelector:@selector(copy)]) {
        // NSObject does not have a -copy method. Install our version.
        struct objc_method_list *mlist =
            malloc(sizeof(struct objc_method_list));
        mlist->method_count = 1;
        mlist->method_list[0].method_name  = @selector(copy);
        mlist->method_list[0].method_types = "v8@0:4";
        mlist->method_list[0].method_imp   = &copy;
        class_addMethods(self, mlist);
    } else {
        // NSObject already implements -copy. Do nothing.
    }
}

@end


-- Greg Parker email@hidden Runtime Wrangler

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com


This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Category conflicts with Tiger
      • From: Scott Anguish <email@hidden>
References: 
 >Re: Category conflicts with Tiger (From: Greg Parker <email@hidden>)

  • Prev by Date: NSMetadataItem question.
  • Next by Date: Re: Developer Group in London
  • Previous by thread: Re: Category conflicts with Tiger
  • Next by thread: Re: Category conflicts with Tiger
  • Index(es):
    • Date
    • Thread