On Wed, 27 Sep 2000, Allan Rae wrote:
> On Tue, 26 Sep 2000, Angus Leeming wrote:
> [...]
> > Angus> Finally, I have made the xforms implementation of FormCopyright a
> > Angus> derived class of FormBase and demonstrated that none of these
> > Angus> FormXXX classes need be dependent on Dialogs.h if they are
> > Angus> passed pointers to the relevant show, hide and update signals
> > Angus> directly by Dialogs.C.
> >
> > Allan> I don't like the looks of this much at all...
> >
> > All fair comment. I was, however, merely trying to demonstrate that it's
> > possible to have one base class that does all this rather nasty stuff. I was
>
> But one base class shouldn't be trying to second guess what it's derived
> classes are going to be doing.
>
> > thinking last night that the production code would merely need a flag
> > definining whether the browser was invariant across all buffers and therefore
> > needed a hideAll signal, or was buffer dependent and therefore required the
> > hideBufferDependent, updateBufferDependent signals.
>
> Just add these lines to FormBase:
>
> /// Derived classes setup signal connections
> virtual void connect() = 0;
> /// Derived classes disconnect signal connections
> virtual void disconnect() = 0;
>
> That way all connections are handled by the derived classes. You could
> alternatively define empty functions so that derived classes that don't
> need extra connections aren't required to implement them but that's more a
> matter of style since no-one is going to create an instance of a FormBase.
D'oh! that's not going to work as simply as that!
show() and hide() should call the derived types connect amd diconnect
methods and for this to work there has to be a pointer/reference to the
derived class passed to the FormBase constructor so we can call
derived_->connect(). Then again a given dialog could just redefine
show() and hide() and avoid all this stuff (or could it?)
You've thrown a googly to me with those new changes in your latest patch.
The arguement below still holds as I still think we need to allow derived
classes to handle extra signals. Table uses extra signals for instance.
It's certainly an interesting twist you've taken with the BufferDependency
idea.
> The stuff that's common (or more specifically identical) between the
> derived classes can go into FormBase. The distinct features of the
> derived classes belong in derived classes. If you try to keep pointers to
> the various signals each different dialog might want to connect you either
> restrict everything to only one update and one hide signal (and possibly
> just one show signal) or you have to keep adding extra signals just so you
> can support some new dialog but such a change would mean recompiling every
> form anyway (the thing you were originally trying to avoid!).
>
> > Same idea as your's for the form property mask.
>
> Good.
>
> > Allan> Anytime someone decides to add an extra signal for a dialog they
> > Allan> have to change Dialogs.C and FormXxxx.[Ch] instead of just
> > Allan> FormXxxx.C (assuming the signal exists or Dialogs.h also if the
> > Allan> signal doesn't).
> >
> > Again, good point. As I was saying, I was just playing! With reflection, the
> > present interface is clean and simple. Think of this submission as a
> > work-in-progress, evolving thought experiment!
> >
> > IF I can make a neat, elegant interface to FormBase, then I definitely think
> > we gain. The resultant daughter classes are immeasurably simpler. Have you
> > seen FormCopyright??? Anyway, I'll press ahead and show you my vision!
>
> We gain a lot already with the existing FormBase. Not much else to fiddle
> with IMO -- apart from the stuff above. You're doing well so far. But if
> you find time do some testing and bug fixing we've really got to get 1.1.6
> sorted.
>
> Allan. (ARRae)
>
>
Allan. (ARRae)
