Re: Renaissance tutorial

[David Ayers]

Nicola Pero wrote:

> 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.
Wow, thanks, you learn something new every day! I'll check next week if 
that already works for OPENSTEP 4.2 and hopefully be able to get rid of 
the custom hack we introduced in the projects I maintain.

> 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 ?
Well I'm a bit torn, on the one hand I dislike offering multiple ways to 
achieve the same goal, on the other hand this is undocumented and 
therefore is (theoretically) more vulnerable to change and (and this is 
the main reason) it's also a bit awkward to handle. (It seems 
reminiscent of the pre-OpenStep, NeXT days.) So I'm not sure whether to 
introduce a new mechanism is a good idea or not.

But if so... your method name suggests using a notification (supplied 
the array becomes the notification object or something similar) and 
having the default method sent automatically to the owner if it 
implements this method. That might even be better as then the object 
graph management could be centralized in an object that listens for 
these notifications. (Opening a third possible approach. :) )

... The more I think about it, the more I like the notification idea, 
but I'll sleep over it. Anyone else an opinion or for a suggestion for 
method or possibly notification name?

Cheers,
Dave

PS: One thing I'm pondering is whether GNUstep should also implement 
this behavior for .gorm files, if we decided to do it for .gsmarkup files.