Am Tue, 15 Jun 2010 09:04:45 +0200 schrieb Mathias Bauer <nospamfor...@gmx.de>:
> So this is code broken (the code in the ItemSet, not yours). I would argue that both code is broken, because as is the ItemSet has no well-defined contract to design against. Of course, Malte is no more guilty than anybody else as the only alternative is not using the broken ItemSet -- which I assume was not an option. > If some code in SfxItemSet just checks for SfxVoidItems to decide > whether it is a disabled item, while other code just checks for ID == > 0, the problem is already there. It's also an unnecessary complexity > to require the check of two attributes (type *and* ID). The next > interesting question is what should happen if items derived from > SfxVoidItems are used ... > > So perhaps coding "disabled" as SfxVoidItem is a severe design flaw. Yes, it is. > So it would be better if disabling (and checking for disabed state) > should be possible only by using explicit methods from SfxItemSet. If > the implementation requires to code that by storing a special item, > this item should be a private class in SfxItemSet so that it can't be > used outside. The problem with that approach is that it requires a > non-trivial amount of work. :-( Well, the implementation in new_itemsets only checks for the which id being 0 and never checks for the type being an SfxVoidItem (outside assertions). So an disabled item is consistently defined as any item returning an which id of 0 in the new itemset implementation. Now the interesting part is finding the clients of the itemset that rely on void items being interpreted as "disabled" by the itemset and fixing those .... Best Regards, Bjoern --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
