discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealloc Notification


From: Helge Hess
Subject: Re: Dealloc Notification
Date: Wed, 14 Nov 2001 11:02:12 +0100

Hi,

I have two issues with that:
a) compatibility (I consider that very critical !!)
b) overhead

Dealloc notifications are IMHO a *very* useful features, but one should
not forget that this isn't available in MacOSX !!! So anything which
uses that feature won't be Foundation portable anymore. This is
especially relevant for GNUstep-base which should be very useful for
MacOSX developers.

Adding an ivar (and a lock) to *each* object can also turn out to be a
significant (memory) overhead (would like to have Java performance ? ;-)

BTW: IMHO one shouldn't use NSNotificationCenter for dealloc
notifications for performance reasons. Eg Apple doesn't do so in EOF
(for objectWillChange notifications) ! 
We could (see above) use a queue for the dealloc-observers directly at
the object.

Like this:

@interface NSObject
{ 
   Class isa;
   struct dealloc_observer {id observer, ...next} *dealloc; 
}
@end

@interface NSObject(ObjectDealloc)
- (void)objectWillDealloc:(id)object;
@end

@implementation NSObject
- ()release {
  ... if RC=0:
    while (self->deallocObservers && rc == 0)
      [observer objectWillDealloc:self];
    if rc still == 0
      [self dealloc];
}

- (void)addObserver:(id)_observer;
@end

Since dealloc-Observers can retain the object, a special -_dealloc BOOL
isn't required.

Greetings
  Helge

Gerrit Van Dyk wrote:
> 
> Richard wrote:
> 
> >There is an NSObject method 'setDeallocNotificationsActive:' you can use.
> 
> This is an instance method that updates a global variable. What was the
> intended purpose of this method? As you mentioned it is so that the _dealloc
> method could return NO and then the object won't be dealloced. The method
> name suggests to me that notifications should be sent when an object gets
> deallocated. If I use this paradigm and add a category to NSObject
> implementing _dealloc which sends notifications then all objects will send
> this notification.
> 
> I have a suggestion. Could we add an ivar to the NSObject class that states
> that a Dealloc notification should be sent when this object are being
> deallocated. If this variable is set on an object then a GSObjectDidDealloc
> notification would be posted in the dealloc method. This will enable any
> object to subscribe to this notification. If an object is interested in a
> notification then you could simply subscribe to the notification and set the
> variable to true. In the DB library I need to know when a DB object gets
> deallocated so that I can remove it from the uniqueing tables. I can set the
> variable to true when I add the object to the tables and subscribe to the
> notification, thus when it gets deallocated I can remove it from the tables.
> I thought that we can implement this ivar in the same way the retained
> variable is implemented ie adding it to the obj_layout structure of
> NSObject, this will not influance other running applications as this
> information is added to the end of the object's instance variables. We will
> need to add a get and set method for this ivar as well.
> 
> If this is acceptable should I implement the changes in NSObject or will
> somebody else do it.
> 
> Just a stupid question, why is there only one lock for all objects for
> setting the retained count? Wouldn't this block to many objects
> unnecessarily. I understand that creating a lock object for each object is
> most probably more of an overhead.
> 
> Regards
> Gerrit van Dyk
> 
> -------------------------------------------------------------------------
> This e-mail is intended only for the use of the individual or entity named
> above and may contain information that is confidential and privileged,
> proprietary to the company and protected by law. If you are not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this e-mail is strictly prohibited. Opinions, conclusions and
> other information in this message that do not relate to the official
> business of our company shall be understood as neither given nor endorsed by
> it.
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep

-- 
SKYRIX Software AG - http://www.skyrix.com
Web Application Technology for Enterprises



reply via email to

[Prev in Thread] Current Thread [Next in Thread]