[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why is +initialize not inherited?
From: |
Larry Campbell |
Subject: |
Re: Why is +initialize not inherited? |
Date: |
Sat, 21 Jan 2006 10:36:07 -0500 |
On Jan 21, 2006, at 4:50 AM, David Ayers wrote:
Larry Campbell schrieb:
In Apple's runtime +initialize is inherited (and this is
documented, so
it's not by accident). In gnustep it's not. Is there a good
reason for
this? It seems like a glaring inconsistency -- "subclasses inherit
methods from their superclass _unless_ the method is called
+initialize". Seems to me it would be much cleaner to not special-
case
this and for +initialize to be inherited.
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)
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]
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.
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)
- lc