I would vote +1 for a more attractive, professional and user-friendly API. I'm not sure if there's a perf or memory-usage reason for using "std::shared_ptr<?>" to types instead of returning values, but the end result does not look like a professional API to me.
I would favor a more user-friendly API. If there's a performance or memory constraint to returning value instead of shared ptr then applying such a pattern to getRegion is overkill at the wrong level of abstraction -- the user can easily keep the return value in a var instead of repeating the Cache::getRegion call. On Mon, Sep 18, 2017 at 3:23 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > So, now that we have selected to use the value model for > CacheFactory::create()/Cache, we need to look at what the methods on Cache > return. > > Starting with Cache::createRegionFactory method which returns > std::shared_ptr<RegionFactory>. I think it is very clear that this should > be a value type. > > RegionFactory Cache::createRegionFactory(...) const; > > > Looking then at Cache::getRegion things are more interesting. It currently > returns std::shared_ptr<Region>. Internally we keep a set of these > shared_ptrs in a map. Does it make sense to keep returning these > shared_ptrs or should we again switch to a value model? It would be great > for consistency on the public API to go the value model way even if > initially the value simply holds a shared_ptr to the internal region impl. > > Thoughts? >
