Skip navigation.
 
mlRe: Inserting a custom class into class hierarchy?
FROM : Ken Anderson
DATE : Fri Dec 03 23:59:05 2004

It's really considered bad form to override methods with categories. 
The runtime does not guarantee any particular override order.  Of
course, if it's the only category overriding dealloc, it will work :)

On Dec 3, 2004, at 5:17 PM, Jim Thomason wrote:

> Now that should be possible with a category.
>
> @interface NSObject (deallocater)
>
> -(void) dealloc {
>    NSMutableDictionary* dataBucket = [self getDictionarySomeHow];
>    [dataBucket removeObjectForKey:[NSString stringWithFormat:@"%p",
> self]];
>    NSDeallocateObject(self);
> }
>
> @end
>
> or something like that should do it. Not having used
> NSDeallocateObjec, I'm not sure of the specifics, but you may need to
> override alloc as well.
>
> + (id) alloc
> {
>    return( NSAllocateObject( self, 0, NULL));
> }
>
>
> + (id) allocWithZone:(NSZone *) zone
> {
>    return( NSAllocateObject( self, 0, zone));
> }
>
> -Jim....
>
>
> On Fri, 03 Dec 2004 15:07:16 -0500, Ken Anderson <<email_removed>>
> wrote:

>> The downside if this approach (I was typing the same thing when I
>> received this email!) is that you don't know when to remove the
>> objects
>> from the dictionary unless your eventual subclass of the objects calls
>> a special method in -dealloc.
>>
>>
>>
>> On Dec 3, 2004, at 3:01 PM, Jim Thomason wrote:
>>

>>> (forgot to send to the list, as I tend to do)
>>>
>>> This is trivially easy in perl...You could re-write your app in that.
>>> Camelbones is decent. :-)
>>>
>>> Otherwise, off the top of my head, the only solution I can think of
>>> isn't pretty. add a category to NSObject and wire it into a second
>>> databucket object. Use a static NSMutableDictionary to look up, or
>>> something. The have this databucket object store the new instance
>>> data. It's all getting accessed through method calls anyway (RIGHT?),
>>> so it doesn't matter where the data actualy is. It's all blackboxed.
>>> It'd be something like this:
>>>
>>> @implementation NSObject (MyObject)
>>>
>>> static NSMutableDictionary* lookup;
>>>
>>> // foo attribute
>>> -(id) foo {
>>>  //key off the memory address (or some other unique value, as
>>> appropriate)
>>>  NSMutableDictionary* bucket = [lookup objectForKey:[NSString
>>> stringWithFormat:@"%p", self]];
>>>  if (bucket == nil) {
>>>    bucket = [NSMutableDictionary dictionary];
>>>    [lookup setObject:bucket forKey:[NSString stringWithFormat:@"%p",
>>> self]];
>>>  }
>>>
>>>  return [bucket objectForKey:@"foo"];
>>> }
>>>
>>> And so on. It's tedious, and quite possibly slow. And tedious (since
>>> you'd always need to do the bucket checks and re-create it at every
>>> attribute call), but that could be automated.
>>>
>>> I haven't tested it and don't plan to, but it's worth a shot.
>>>
>>> Another option would be to subclass each of the GUI elements, and add
>>> in the extra instance variables and such there. Gets the same stuff,
>>> just from a different location.
>>>
>>> But, it also doesn't strike me as very objective-C-ish. Perhaps you
>>> could accomplish similar things with categories and delegation? Why
>>> do
>>> -all- objects in the system _need_ these additional values anyway?
>>> Can't you get by with simply tacking them onto your model objects?
>>>
>>> -Jim....
>>>
>>>
>>>
>>>
>>> On Fri, 03 Dec 2004 12:33:26 -0600, Alex Majora
>>> <<email_removed>> wrote:

>>>> I am on a very large project, so I've established a common custom
>>>> class,
>>>> MyObject, inserted beneath NSObject for all of our objects that
>>>> inherit
>>>> directly from NSObject; In this way, we can add all of our common
>>>> functionality and instance variables there, so there's no
>>>> duplication
>>>> amongst the various classes.
>>>>
>>>> So far so good.
>>>>
>>>> However, for objects that necessarily must subclass from GUI
>>>> elements
>>>> like
>>>> NSImageView, NSQuickDrawView, etc., I don't see a way to do this.
>>>>
>>>> In general, I'm not a fan of multiple inheritance, but it would be
>>>> handy in
>>>> this case. Simply adding a category to NSObject doesn't allow us to
>>>> add
>>>> instance variables, so that's out. I don't see any way to "insert" a
>>>> custom
>>>> class into an established hierarchy. And I certainly don't want to
>>>> replace
>>>> NSObject, for obvious reasons. Any ideas?
>>>>
>>>> Thanks!
>>>> Alex
>>>>
>>>> _______________________________________________
>>>> MacOSX-dev mailing list
>>>> <email_removed>
>>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>>

>>> _______________________________________________

>>
>>

>>> MacOSX-dev mailing list
>>> <email_removed>
>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev

>>
>>

Related mailsAuthorDate
mlInserting a custom class into class hierarchy? Alex Majora Dec 3, 19:33
mlRe: Inserting a custom class into class hierarchy? j o a r Dec 3, 20:44
mlRe: Inserting a custom class into class hierarchy? Jim Thomason Dec 3, 21:01
mlRe: Inserting a custom class into class hierarchy? Ken Anderson Dec 3, 21:07
mlRe: Inserting a custom class into class hierarchy? Jim Thomason Dec 3, 23:17
mlRe: Inserting a custom class into class hierarchy? Ken Anderson Dec 3, 23:59
mlRe: Inserting a custom class into class hierarchy? Shaun Wexler Dec 4, 00:11
mlRe: Inserting a custom class into class hierarchy? Shaun Wexler Dec 4, 00:12
mlRe: Inserting a custom class into class hierarchy? The Karl Adam Dec 4, 00:38
mlRe: Inserting a custom class into class hierarchy? M. Uli Kusterer Dec 4, 08:58
mlRe: Inserting a custom class into class hierarchy? Shaun Wexler Dec 5, 01:49