While I'm a huge advocate for information-hiding and clean APIs, the purpose of this flag is to implement an optimization in GRExprEngine, so this is really a tightly coupled dance between GRExprEngine and the Checker objects. Note that GRExprEngine is already a 'friend' of the Checker class. There's no need for an accessor at all if we basically want it to be a hidden detail between Checker and GRExprEngine. It then doesn't pollute the public interface of Checker.
On Aug 5, 2010, at 6:35 PM, Jordy Rose wrote: > > I was adhering strictly to information-hiding -- once we're at this point, > it's little better than just accessing respondsToCallback directly. But it > is simpler. I think I went overboard. > > > On Fri, 6 Aug 2010 09:31:17 +0800, Zhongxing Xu <[email protected]> > wrote: >> Why can't we just do that: >> >> in Checker.h: >> >> bool &getCallbackFlag() { >> return respondsToCallback; >> } >> >> In GRExprEngine.cpp: >> >> + SaveAndRestore<bool> OldFlag(checker->getCallbackFlag(), true); >> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
