Today, having forgotten this five-year-old conversation, I was burned by this again.
I cannot think of any good reason (other than inertia) for +initialize not to be inherited as it is on Mac OS X. It's incompatibilities like this that make it hard to recommend Objective-C. Does anyone else care about this? - lc On Jan 21, 2006, at 1:31 PM, David Ayers wrote: > Larry Campbell schrieb: >> On Jan 21, 2006, at 4:50 AM, David Ayers wrote: >> >>> >>> Have a look at this discussion: >>> >>> http://lists.apple.com/archives/objc-language/2004/Mar/msg00006.html >>> >>> Now, I'm no advocate of being different just for the sake of being >>> different, but I also think that '+load' and '+initialize' are simply >>> "special" wrt inheritance and guarantees on how/when they are called and >>> I would assume that we would break code written for the FSF libobjc >>> runtime if FSF's libobjc started to inherit +initialize. >> >> >> However, I think that: >> >> 1. The difference between FSF here and Apple is a trap for the unwary >> 2. It would be best to remove such traps when possible >> 3. Due to binary compatibility it's extremely unlikely Apple will change >> 4. There's no clear advantage to the FSF approach (or the Apple approach) > > All of these points could be applied for most of the FSF libobjc API. > (E.g., did you know that the class pointer of an 'id' in FSF's libobjc > is called 'class_pointer' instead of 'isa'? But yes, I realize the > inconsistency that Object.h still uses 'isa' as the ivar name.) > > The reasons are historical and I assume have to do with the reluctance > of NeXT to release their GCC modifications to ObjC in the first place. > I kind of doubt that the FSF wanted to make their libobjc incompatible, > but I don't know the details of what happened and they seem to diverge > quite a bit more than I would have expected... Anyway, now there is > code out there that relies on FSF's libobjc and we should consider > changes carefully. > >> 5. If you really want to share initialization code with subclasses, you >> have to move such initialization code into a separate method, or >> subclasses have to call [super initialize] > > Moving them to separate methods that get invoked by +initialize seems > like the most robust approach to me. > >> So I think I would argue that FSF should consider changing; not >> precipitously, and with perhaps a way to override via an environment >> variable in case of compatibility bugs. > > Well this is the type of discussion that the above mentioned list was > created for. I am personally undecided on the issue and would insure > that any code I write today would be portable. Even if it is decided to > change the GNU semantics I believe the earliest libobjc release would be > 4.2 (or possibly 4.3 depending on libobjc maintainers view this in light > of the pending switch to Stage 2 of gcc's trunk) and any code relying on > NeXT/Apple semantics would have to wait until that compiler version is > in wide spread use. > >>> Note that if you actually invoked either +initialize or +load in a true >>> method invocation, the normal inheritance techniques would be used. But >>> be warned, code often is not prepared for multiple invocations of these >>> methods and could break in strange ways (e.g. replacing objects/caches >>> which were meant to be initialized as singletons). >> >> >> Yes, sadly all my initialize methods now have to look like this: >> >> + (void)initialize >> { >> if (self == [MyClass class]) { >> static BOOL inited = NO; >> if (!inited) { >> // do stuff >> } >> } >> } >> >> (This still doesn't help with category initialize, but I try to avoid >> categories and I've never tried category initialize) > > Category +initialize is a different story all together. Please read > that thread closely and then maybe you can propose semantics that we can > be discussed on that list. > > - Should a category be able to replace the +initialize implementation of > a class? > - Should it be sent if the category is loaded after the first method > (and therefor the initial +initialize invocation has already been executed)? > - Should it only be sent on the first invocation of any method that the > particular category implements rather than any method the class implements? > - What is the expected hit on standard runtime method invocations if you > have to do all that checking during method dispatch? > > When I went through all of that, I decided that +initialize on a per > category basis can not give the guarantees I would like and stay > efficient at the same time. But maybe you have some new ideas. > > Cheers, > David _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
