On Wed, Jan 30, 2002 at 08:08:22AM +0200, Martin Vermeer wrote:
> ...and feel free to explain what you mean... if this is clear to both of you,
> to me it is Chinese ;-)
The 'InsetCode' stuff is (from a strict OO point of view at least - which I
not always support) a bad thing.
An object should identify itself by its behaviour, not by providing some
magic value and pushing the responsibility to 'get it right' to 'user code'.
The 'clean solution' would be to create some
virtual bool canBePutIntoALabel() const { return false; }
into the inset base class and override this by putting
virtual bool canBePutIntoALabel() const { return true; }
in the classes that 'have this property'. User code simply has to call
inset->canBePutIntoALabel()
to learn whether this inset can be put in a label or not.
If religious reasons don't count much for you imagine what happens when
we add a new inset that derives from and inset with canBePutIntoALabel() ==
true. With the InsetCode 'solution' you have to add the proper InsetCode
to the if() in the user code, with the 'proper' solution you do not have to
do anything. It just works.
Now you might argue that adding another case to the if() is not much work.
Fair enough... But how do you tell which user code is affected without
checking _each_ file manually? And what happens to your if-clauses if we
have 30 insets?
Andre'
--
André Pönitz .............................................. [EMAIL PROTECTED]
