On 11/02/2011 05:21 PM, Michael Meeks wrote:
The benefits of the stable ABI requirement are somewhat unclear to me.
Mostly for the benefit of (external) client code. Also, as a secondary
effect, striving for a stable API probably tends to make the authors of
the API work harder to produce good quality (documentation, minimalism,
orthogonality, ...; at least, that's my personal experience).
If (as seems ~certain) we are going to have a flag day at some stage,
there is no harm moving this little lot into the sal/ library. To what
Sorry, don't get what you mean with "flag day" here.
So - I think this splitting code into lots of different places for ABI
reasons can be re-considered.
An API should strive for various, potentially competing qualities.
Stability is one, discoverability is another. Finding a good balance
here can be a delicate exercise, and there is no single "right" answer.
The concept of additional, external convenience APIs is quite
widespread. So is the wisdom of "if in doubt, leave it out." Confer,
for example, chapter 2 of Reddy's "API design for C++" (MK, 2011).
Those are quite general remarks, meant more as something to keep in the
back of your mind while working on LO's stable URE API, than as litmus
tests how to handle the comphelper/string.hxx under discussion here (for
which the case-by-case approach already discussed by Caolán sounds
reasonable).
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
