To me the question of a no-op region comes down to whether customers would need
to do logic based on whether a region has a parent. If they do, perhaps a bool
hasParent() along with getParent() returning a no-op region would be an elegant
solution. If they do not, then shared_ptr is probably suf
Yes, but I wouldn't expect to ever need to do a type check. Admittedly, I'm
not sure what one does with parent region, but if we no-op, return sensible
empty values, or throw when appropriate then maybe we don't care?
I would expect it to be used something like this:
auto parent = region.getParen
Are you thinking something like?
class NoRegion : public Region {...};
auto parent = region.getParent();
if (NoRegion == parent) {
// no parent region
}
On Tue, Oct 10, 2017 at 11:08 AM David Kimura wrote:
> I'm not sure if this is the same as the sentinel value you mentioned, but
> what ab
I'm not sure if this is the same as the sentinel value you mentioned, but
what about introducing a no-op region type and returning that? I'm
thinking a null object pattern which would no-op and then nobody should
need to check if nullptr.
Thanks,
David
On Tue, Oct 10, 2017 at 10:27 AM, Jacob Bar
Looking at a class like Region (Region.cpp) there are calls to get the
parent region and sub regions, there are instances where a Region will not
have a parent or subs. The current API returns shared_ptr that may be
nullptr or a Region.
Since we are trying to make an effort towards values over poi
