On Fri, Jul 6, 2012 at 2:26 PM, Joe Mason <jma...@rim.com> wrote:
> > From: Filip Pizlo [fpi...@apple.com]
> > Sent: Friday, July 06, 2012 4:52 PM
> > To: Joe Mason
> > Cc: WebKit Development [webkit-dev@lists.webkit.org]
> > Subject: Re: [webkit-dev] Pointers and self-documenting code
> >
> > It's not at all clear that this is correct.
> >
> > Is it correct for the font size to be zero if the frame doesn't exist?
> Seems
> > dubious.
> >
> > Is it correct for the font size to be zero if the page doesn't exist?
> Seems
> > dubious.
> >
> > Adding null checking only makes sense if you have a good story for what
> the
> > code ought to do if the pointer in question is null.
>
> Well, yes, but that's not the point of the example. I thought about
> adding a comment, "or some suitable default," but I figured that would be
> pedantic.
>
> Regardless of whether my example default was a good one, it's clear that
> dereferencing null and crashing is NOT the correct thing to do.
>
> > This is a questionable policy. Often object properties have transient
> > nullness. They may be null at time T1 and non-null at time T2, and the
> caller
> > may know that the property is non-null from context (the value of some
> other
> > field, the fact that it's performed some action that forces the field to
> > become non-null, etc).
>
> In this case the caller should specifically assert that the property is
> not null, to let the person reading the code know that it's a possibility
> that's been considered and it's believed to be impossible.
>
> > Thus statically enforcing the non-nullness of fields is likely to just
> make
> > the code more complicated. And it doesn't buy anything.
>
> It buys a lot! It buys clarity. It makes the code less fragile. It's a
> lower barrier to entry, because less knowledge is needed to understand the
> code. In some cases it provides a compile-time correctness guarantee,
> which is a good thing - not in all cases, but sometimes is better than
> never.
>
> There are three categories of accessor:
>
> 1. Those that can never return null
> 2. Those that can potentially return null, and in circumstances complex
> enough that developers can't usefully keep track while writing algorithms
> 3. Those that can potentially return null, but only in circumstances that
> are well defined and easy to reason about (the "transient nullness" you
> mention)
>
> For type 1, I argue that we should return references to indicate this
> statically. I don't see how this makes the code more complicated.
>
This change seems valuable. I've seen a lot of code & patches where people
did something along the line of:
Editor* editor= m_frame->editor();
if (!editor)
return;
Note that Editor is a member variable of Frame and we just return &m_editor
in editor().
- Ryosuke
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
