For me optional seems very misleading and generally different prefixes
suggests that those objects are not the same.
Maybe IfExists does not sound nicely but at least it's clear. I would
choose to have a pointer version with IfExists and a reference version
which is a noun, like:
StyleResolver* styleResolverIfExists()
StyleResolver& styleResolver()
Br,
-Balazs
On 06/19/2013 10:28 AM, Maciej Stachowiak wrote:
On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa <rn...@webkit.org
<mailto:rn...@webkit.org>> wrote:
On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser <simon.fra...@apple.com
<mailto:simon.fra...@apple.com>> wrote:
On Jun 18, 2013, at 7:11 PM, Darin Adler <da...@apple.com
<mailto:da...@apple.com>> wrote:
On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa <rn...@webkit.org
<mailto: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
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.
I don't think possible lazy creation is a good reason to decorate the
name. Functions should be named for what they do, not their presumed
efficiency.
I am also not sure we need a style guideline about putting things into
variables. If it makes a difference in a hot code path, then sure, but
most of the time, the more concise code is better.
- Maciej
- R. Niwa
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto: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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
