On Tue, Feb 18, 2003 at 02:44:11PM +0000, Angus Leeming wrote:
> I think I have just about cleaned up the controllers code so that it is now
> transparent. As a result of this clean-up I have managed to replace all
> those boost::signals in frontends/Dialogs.h with normal C++ class methods.
Good stuff.
> Similarly, I am about to replace the
> boost::signal0<void> hideDialog;
> that appears in the insets code with a class method also.
>
> This leads me to a question. Should I override the inset destructor as is
> done now:
>
> insets/insetbase.h: virtual ~InsetBase() {}
> insets/insetcommand.h: virtual ~InsetCommand() { hideDialog(); }
>
> Or should I have:
> insets/insetbase.h: virtual ~InsetBase() { hideDialog(); }
> insets/insetbase.h: virtual void hideDialog() {}
>
> and overide hideDialog in those inset classes that actaally do have a
> dialog? Which is considered to be "better style"?
Not sure. I personally would lean to the first option, as the InsetBase
ideally does not know anything about dialogs
(which, of course is not true, as it has to declase 'hideDialog'...).
I think it's like varaible definition: Do it as late as possible but not to
the extent where it hurts...
> It may be that the approach is redundant as the frontends/Dialogs.h code is
>
> class Dialogs {
> public:
> ///
> void Dialogs::hide(string const & name){
> if (isValidName(name))
> dialogs_[name]->hide();
> }
> };
>
> So, I could have this and let it do the right thing:
>
> class InsetBase {
> virtual ~InsetBase() { getDialogs().hide(name()); }
> virtual string const & name() const = 0;
> };
I am not sure I like such "complex" things in the InsetBase.
The majority of insets (i.e. most math insets) won't have dialogs...
Maybe putting the "hide" in InsetCommand or similar would be ok?
> Could someone show me which of these three solutions is "best" ?
It's a matter of taste I believe.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
