Re: Inserting a custom class into class hierarchy?

FROM : Jim Thomason
DATE : Fri Dec 03 23:17:20 2004

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
>
>