On 13/10/2010 18:43, Malte Timmermann wrote: > I wonder: My assumption is that SfxItemPool::GetItemCount() will still > return USHORT, right?
actually Bartosz has changed it to return size_t, and i think this is right. > We just change one implementation detail (internal array will use a > different container), but we don't change the SfxItemPool API (which > probably would be the CWS new_itemsets, where we also might change API, > don't know). i don't think new_itemsets wanted to change anything with the SfxItemPool, only the SfxItemSet, right, Bjoern? > Does it really make sense to store anything larger than USHORT, while > the SfxItemPool API is still USHORT? > > I don't think so. > > So I suggest to keep USHORT for persistence, and really only focus on > the task to replace the array implementation and nothing more. > Why introducing unnecessary side effect or possible incompatibilities? there is a very good reason: some people manage to write (or however they do that :) documents that contain > 2^16 charfmt items. this is issue #i84159# which i mentioned in the original mail. it has 39 votes right now. so changing this has clear benefits. -- "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler et al, Refactoring: Improving the Design of Existing Code --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
