Re: Inserting a custom class into class hierarchy?
Re: Inserting a custom class into class hierarchy?
- Subject: Re: Inserting a custom class into class hierarchy?
- From: The Karl Adam <email@hidden>
- Date: Fri, 3 Dec 2004 18:38:11 -0500
Add a poseAsClass to your MyObject to have it pose as NSObject,
however be forewarned that you then need to make sure your app doesn't
explode, the world doesn't end and you didn't tear a hole in the space
time continuum. All that said:
+ (void) load {
// This is to make sure whatever black magic NSObject is responsible for,
// does get started
[super load];
// This is the actual code and now everytime NSObject is requested,
// MyObject will be returned instead
[self poseAsClass:[NSObject class]];
}
P.S. MAKE SURE MYOBJECT DOES INHERIT FROM NSObject ELSE ALL HELL WILL
BREAK LOOSE
Sorry for teh caps, but that does need more emphasis.
-Karl
On Fri, 3 Dec 2004 15:11:08 -0800, Shaun Wexler <email@hidden> wrote:
> On Dec 3, 2004, at 10:33 AM, Alex Majora 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?
>
> malloc granularity dictates that pointers are returned in multiples of
> 16 bytes, which are aligned to 16-byte addresses, thus the low 4 bits
> are always clear for object pointers ("id"). All you need to do is
> decide how many bytes of private object storage you need, round that up
> to a multiple of 16 bytes, and override NSObject +allocWithZone: to
> alloc memory with the increased length which is >= 32. Set the
> object's isa pointer to the first 16-byte address beyond your custom
> ivar's, and write custom accessor methods for the hidden ivar's.
> Everything else should be automatic, and transparent to the rest of
> Cocoa; CF-bridged objects won't be allocated this way, though; you'll
> have to override the default CF allocator as well.
>
> If you enforce 32-byte alignment and granularity of your objects (which
> I do, but only in my base SKWObject subclass of NSObject) then you'll
> also enjoy a speed enhancement on G3/G4 due to native cacheline
> orthogonality, and you can use 128-byte granularity on G5, if memory
> usage will not be an issue... remember that if you override NSObject,
> all objects will increase in length, and there are many thousands of
> hidden objects you never knew existed. I've never tried prepending
> ivar's like this, but it should work. Untested, written in Mail.app:
>
> typedef struct MyCustomIvarStruct16 {
> int myHiddenIvar;
> int moreIvars[7];
> } MyCustomIvarStruct;
>
> 00 myHiddenIvar <first byte of custom object>
> ...
> 10 isa <first byte of normal object, *id>
> ...
> 1f <last byte of object>
>
> HTH~
>
> // multiple of 16 bytes, >= 16
> #define myCustomObjectLengthBytes 16
>
> id AllocCustomObject(Class cls, int len)
> {
> if (cls && len) {
> void *buf = malloc(len + myCustomObjectLengthBytes);
> if (buf) {
> id obj = buf + myCustomObjectLengthBytes;
> *object = cls; // self->isa
> return obj;
> }
> }
> return NULL;
> }
> --
> Shaun Wexler
> MacFOH
> http://www.macfoh.com
>
>
> _______________________________________________
> 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
>
>
>
_______________________________________________
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