[webkit-reviews] Patch to fix initialization issues in
the WebView subproj
mjs at apple.com
Sun Jun 12 16:22:37 PDT 2005
On Jun 12, 2005, at 3:38 PM, Darin Adler wrote:
>> 2. did not set self to the return value of the superclass, or
> I don't think this is important.
> While it's true that classes can use the technique where they
> return a different value from init, it's not necessary to always
> code as if your superclass does this. The vast majority of classes
> don't do this, and never will, and writing all the code as if they
> do doesn't provide a practical improvement.
> On the other hand, I think there's not great harm in doing this
> either; it won't really make the code bigger and it's nice to be
> more consistent.
I think for this and the check for a nil return value, it's better to
always have the check than to have to waste brain cells determining
where it is needed. In theory it would be a fine alternative to
instead put a comment in the places where assigning self is
guaranteed not to be needed, but it seems like a bunch of work to
>> 3. did not check to see if the superclass initializer actually
>> returned anything, or
> Again, just because some classes can fail initialization and return
> nil doesn't mean that every class can do this. There are many
> classes that simply do not have a failure case, and adding code to
> check in those cases doesn't necessarily enhance things.
My feeling on this is same as above - would be nice to have either
the nil check or a comment stating it's not needed. Even though the
nil check case would often be dead code. What do you think, Darin?
> I like the suggestion of using:
> if (!self)
> return nil;
I like this way better too.
More information about the webkit-reviews