bug-gnustep
[Top][All Lists]
Advanced

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

Re: [Fwd: RFC GDL2: move +load implementations to +initialize]


From: David Ayers
Subject: Re: [Fwd: RFC GDL2: move +load implementations to +initialize]
Date: Fri, 17 Jan 2003 17:54:55 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

Mirko Viviani wrote:

David Ayers <d.ayers@inode.at> ha scritto:

In the very unlikely event that no messages get sent to EODatabaseContext before the the EOCooperatingObjectStoreNeeded Notification gets posted, we should just make sure to call some EODatabaseContext method (like [EODatabaseContext class]) real early to force the runtime to send +initialize to EODatabaseContext.

The problem is really this... how to be sure that a message will be sent to
these classes ?

I must admit, if you really want to catch this case of:

int main (int argc, char **argv)
{
 EOCooperatingObjectStore *coopstore;

coopstore = [[NSNotificationCenter defaultCenter] postNotification: @"EOCooperatingObjectStoreNeeded"
   object: nil]
}

then I'd have to pass this on to the real objc runtime experts.

But lets see what we can do...

The current implemetaion of _registerDatabaseContext: either needs some EOGlobalID, EOFetchSpecification or a customEntityObject. In the later case (customEntityObject) we can be pretty sure that EODatabaseContext has been initialized. So putting an [EODatabaseContext class] in the implemetatiin of +initialize of EOFetchSpecification and EOGlobalD would put us on the very safe side for any 'legal' notification.

The implementation of _registerDatabaseChannel: expects an EODatabaseContext in the notification, so we could add a [EODatabaseChannel class] to EODatabaseContext's implementation of +initialize.

I think this should be all the security we need.

Cheers,
Dave








reply via email to

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