[webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

[Balazs Kelemen]

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 <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())
>>     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 at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130619/e270f747/attachment-0001.html>