gnustep-dev
[Top][All Lists]
Advanced

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

Re: Multiple _OBJC_Module in the same shared library/framework, not so g


From: Richard Frith-Macdonald
Subject: Re: Multiple _OBJC_Module in the same shared library/framework, not so good
Date: Sun, 8 Jan 2012 14:48:39 +0000

On 7 Jan 2012, at 16:39, Nat! wrote:

> 
> Am 07.01.2012 um 16:32 schrieb David Chisnall:
> 
>> 
>> On 7 Jan 2012, at 15:19, Nat! wrote:
>> 
>>> Why is +load crucial ? +load is a convenient initialization place, when you 
>>> are mixing C/ObjC and you can't guarantee that +initialize is called before 
>>> the C-code. You can use it for augmenting categories, where the +load 
>>> method initializes some stuff. Also it should be a reliable way to patch 
>>> third-party objc libraries one links against. Not having the last 
>>> capability means, that you are possibly maneuvering yourself in a dead-end 
>>> (on the objc level). 
>>> 
>>> A +load with only the most minimal semantic guarantees is therefore useless 
>>> to me.
>> 
>> You won't get that guarantee in any language.  Global initialisers in C++, 
>> __attribute__((constructor)) in GNU C, and +load in Objective-C all 
>> EXPLICITLY come with no ordering guarantee between compilation units.
>> 
>> +load actually comes with the strongest guarantee, because it guarantees not 
>> to be run until after all superclasses have been loaded.
> 
> Good, because first you call me an idiot, because there aren't any 
> guarantees. And then you give me the one I wanted to hear :) Because that 
> guarantee is actually much more than I expected after the current discussion.
> 
> If I look at Apple's NSObject +load documentation, and ignore the 10.5 part 
> there as being OS machine specific, it distills down to:
> 
> ---
> A class’s +load method is called after all of its superclasses' +load methods.
> A category +load method is called after the class's own +load method.
> In a +load method, you can therefore safely message other unrelated classes 
> from the same image, but any +load methods on those classes may not have run 
> yet.

Your third point here does not follow from the others  ... unless by 'safely' 
you are talking about a very specific case:
You can call methods in unrelated classes in the same compilation unit, as long 
as those methods do not (directly or indirectly) call other methods which do 
not obey the same rule.
So, yes you can construct code which works to call various methods from +load, 
but it's so fragile that calling it 'safe' would be perverse.

In practice that boils down to the rule that you can't safely call any ObjC 
code from within +load (irrespective of whether you are talking about Apple or 
GNU) ... you need to stick to C code in order to avoid someone (perhaps you) 
coming back to the code later and inadvertently breaking it by modifying one of 
those other methods your +load calls.

All is not lost though ... you can almost always get the sort of effect you 
want by using +load to set variables which are used later in +initialize 
methods.






reply via email to

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