On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser <simon.fra...@apple.com> wrote:
> On Jun 18, 2013, at 7:11 PM, Darin Adler <da...@apple.com> wrote:
>
>> On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
>>
>>> Why don't we call it requireStyleResolver() instead?
>>
>> I’m warming to this idea. Maybe we can use “require” as a term of art,
>> analogous to the way we use “create”, to mean “create if not already
>> created”.
>
> Since the fact that it returns a reference implies that it must create
> something if necessary, the “required” part of the name seems redundant. Why
> not just
> StyleResolver& styleResolver()
>
> requireStyleResolver() sounds like it would return a bool.
>
> True. But it's important to differentiate a simple inline accessor and a
> lazily-create function because it's very easy to write code like:
>
> if (styleResolver().x())
> styleResolver().y();
>
> and incur two function calls when we could have done
OOI Is the lazily-create function not inlined? – I wouldn’t expect to pay two
function calls here, since the method is in the header & looks simple enough:
StyleResolver* ensureStyleResolver()
{
if (!m_styleResolver)
createStyleResolver();
return m_styleResolver.get();
}
I imaging we may perform the branch twice, since it may not be apparent to the
compiler that m_styleResolver is non-null after the first call – though I guess
this is necessary since theoretically x() could clearStyleResolver.
> StyleResolver& resolver = styleResolver();
> if (resolver.x())
> resolver.y();
>
> instead.
>
> On the other hand, I've started to think that maybe we can simply forbid the
> former style altogether in the style guide so that we'll never have to think
> about whether a given function is inline or not.
>
> - R. Niwa
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
