[webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo
kbalazs at webkit.org
Wed Jun 19 08:49:35 PDT 2013
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:
On 06/19/2013 10:28 AM, Maciej Stachowiak wrote:
> On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa <rniwa at webkit.org
> <mailto:rniwa at webkit.org>> wrote:
>> On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser <simon.fraser at apple.com
>> <mailto:simon.fraser at apple.com>> wrote:
>> On Jun 18, 2013, at 7:11 PM, Darin Adler <darin at apple.com
>> <mailto:darin at apple.com>> wrote:
>>> On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa <rniwa at webkit.org
>>> <mailto:rniwa at 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())
>> and incur two function calls when we could have done
>> StyleResolver& resolver = styleResolver();
>> if (resolver.x())
>> 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
> 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 at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev