replacing OUString::valueOf(static_cast<sal_Int32>) ??

[Noel Grandin]

On Thu, Jan 10, 2013 at 5:31 PM, Lubos Lunak <l.lunak at suse.cz> wrote:

> On Thursday 10 of January 2013, Noel Grandin wrote:
> > On 2013-01-10 15:55, Lubos Lunak wrote:
> > > - There's no need for valueOfChar(). There is already OUString ctor
> from
> > > sal_Unicode, so the valueOf() overload for it is just making an obvious
> > > thing complicated. Code using it can be converted to use the ctor
> > > instead.
> >
> > Which doesn't help with overload resolution problems.
>
>  It does. If you say it's wrong to use valueOfWhatever() for char->string
> conversion, there either will not be problems, or it will be wrong. If you
> want to fix an existing problem by introducing a new function, how does
> that
> make anything better than using an already existing function that does the
> job?
>
>
You are correct, we are indeed talking past each other.
If you go back to the very first message in this thread, the patch
mentioned there will perhaps help to establish come context.

But I will try to explain again.

The constructors and existing methods don't help because the specific
problem we are trying to solve is that the C++ overload resolution rules
will sometimes pick a non-intuitive method or constructor to apply.

This leads to code that looks like:

aStyleName.Append( OUString::valueOf( static_cast<sal_Int32>( nDepth ) ) );

which is the integer case. Similar problems apply to the char and bool
cases.

The purpose of these methods is purely to reduce this boilerplate coding
and increase readability, so that we have:

aStyleName.Append( OUString::valueOfInt( nDepth ) );

Given that our string classes are used pretty much everywhere, having a
wide API that increases readability can only be a good thing.

While you might not like the names of the new methods, I don't see how
making the names of the new methods dramatically different from the names
of the existing "valueOf" methods can be an improvement to the API.
Sometimes, we have to work with what we have.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130110/e34ca331/attachment.html>