[webkit-reviews] Patch to fix initialization issues in the WebView subproj

[Maciej Stachowiak]

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  
determine that.

>> 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.

Regards,
Maciej