discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Renaissance tutorial


From: Nicola Pero
Subject: Re: Renaissance tutorial
Date: Sat, 4 Jan 2003 18:50:10 +0000 (GMT)

> >I appreciate comments and suggestions (and bug reports) as usual. :-)
> >
> >  
> >
> Hello Nicola,
> 
> Great job! This seems to be exactly the nib replacement I've been hoping 
> for!  I haven't tried it yet, but a quick glance at the tutorial and 
> short scan of the source revealed that one of my itches about nib files 
> wasn't scratched with Renaissance though.  It has to to with memory 
> management.  Nibs simply leak (yes, you can partially avoid it by 
> connecting (or programmatically collecting) all objects you can 
> programmatically reference and send an extra release during the owners 
> dealloc, yet some of the internal nib-collection objects always remain, 
> though they don't use a lot of memory.  In large projects (200+ bundles) 
> this can be very annoying and error prone.
>
> I'm not 100% sure if Renaissance doesn't addresses this issue, but if 
> not, I would suggest that during loadGSMarkupNamed:owner: the owner 
> could be asked if it implemented a method like 
> -(void)takeOwnershipOfObjectGraph:(id)rootObject (or anything similar) 
> and if so invoke it and (auto)release the rootObject.  That way the 
> owner can take control of object graph and release it when apropriate. 
>  Maybe some extra code in the rootObjects dealloc would also be needed 
> to break any cyclic references in the graph objects, but that would be a 
> second step.

Renaissance at the moment works in the following way:

 - objects created from a gsmarkup are not released, nor autoreleased.

 - if you add a NSTopLevelObjects key, with value a NSMutableArray, to the
name table when you load the gsmarkup file, then all the top level objects
created from the gsmarkup file are added to this array.  You can then
release/autorelease/destroy them whenever you want.  Because you have the
top level objects, if you destroy them, no other object from the gsmarkup
should remain.

This is actually the same way in which nibs work too -- even if this
NSTopLevelObjects 'hack' is not documented, it's there too.

It seems you are suggesting a different way of letting the program get the
list of the top-level objects - that if the file owner responds to a
certain method, say

 - (void) didLoadObjectsFromGSMarkup: (NSArray *)topLevelObjects;

then it's called, with the top level objects as argument in an array.

I quite like your proposal :-) it frankly seems better than the nib hack.

Any suggestion for a good method name ?





reply via email to

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