Robert Collins wrote: > On Sat, 2003-07-19 at 23:40, Max Bowsher wrote: >> Gary's current SetupXP patchset calls 2 member functions on page activation: >> OnActivate (returns void), and OnAcceptActivation (returns bool). I think >> this is unnecessarily messy. AFAICS, OnAcceptActivation only exists to >> prevent the need to change the return type of the existing OnActivate >> function. >> >> I would very much prefer changing OnActivate to return bool, combining the >> purpose of both functions. Yes, this does require changes in all derived >> classes, but the changes are trivial, and the end result is a cleaner, more >> logical API. > > If its what I think you are talking about, I disagree. > > OnAcceptActivation was, IIRC, prompted to allow pages to accept or > refuse activation. Refusing == don't display. Accept = display. > > OnActivation, is called on each activation, which only occurs > post-accept checking. > > OnAcceptActivation can have default behaviour for the common case, > reducing duplicate code over a conflated function that both activates > and indicates whether it's willing to be activated. > > Naming wise though, I'd call OnAcceptActivation canBeActivated or some > other query-indicating function. > > Again, all the above is based on recollection..
Right. One detail though, at the moment, OnAcceptActivation is called *after* OnActivate. That *is* redundant. Unless there will ever be a need to ask a page whether it would take activation in the future, but not activate it immediately, even if it is possible to do so, I think the 2 calls should be merged. Will there ever be such a case? Max.