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

[Maciej Stachowiak]

On Jun 19, 2013, at 4:22 PM, Elliott Sprehn <esprehn at chromium.org> wrote:

> 
> On Wed, Jun 19, 2013 at 9:46 AM, Andreas Kling <akling at apple.com> wrote:
> On Jun 19, 2013, at 6:37 PM, Timothy Hatcher <timothy at apple.com> wrote:
> 
>> What about?
>> 
>> StyleResolver* existingStyleResolver()
>> StyleResolver& styleResolver()
> 
> 
> This doesn't make sense since calling styleResolver() again won't create a new one so it's also "existing style resolver".
> 
> I rather like the foo() and ensureFoo() methods. foo() is just a plain getter like any other method, the class may start with:
> 
> setFoo(Foo*);
> Foo* foo();
> 
> later we want to also allow optionally created when needed so we add:
> 
> Foo* ensureFoo();
> 
> The current naming and methodology makes a lot of sense. fooIfExists() always bugs me because there's no reason to decorate a getter that is just a plain getter. Adding an ensureFoo() method shouldn't make me rename the existing foo() method to fooIfExists().

Personally, I think lazy creation is a more natural getter semantic than getting only if something already happened to trigger creation. So I think fooIfExists/foo is a more natural pair than foo/ensureFoo. But I agree with others on the thread that optionalFoo or existingFoo might be better names, particularly given std::optional.

(It might even make sense to have optionalFoo methods return a std::optional holding a reference instead of a raw pointer, if it would not be too much of a perf hit.)

Regards,
Maciej

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