On Jun 19, 2013, at 4:22 PM, Elliott Sprehn <espr...@chromium.org> wrote:
> > On Wed, Jun 19, 2013 at 9:46 AM, Andreas Kling <akl...@apple.com> wrote: > On Jun 19, 2013, at 6:37 PM, Timothy Hatcher <timo...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
