<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 10, 2013 at 5:31 PM, Lubos Lunak <span dir="ltr"><<a href="mailto:l.lunak@suse.cz" target="_blank">l.lunak@suse.cz</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Thursday 10 of January 2013, Noel Grandin wrote:<br>


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

<div style><br></div><div style>But I will try to explain again.<br></div><div style><br></div><div style>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.</div>

<div style><br></div><div style><font face="arial, helvetica, sans-serif">This leads to code that looks like:</font></div><div style><font face="arial, helvetica, sans-serif"><br></font></div><div style><span style="font-family:arial,helvetica,sans-serif"></span><span style="font-family:arial,helvetica,sans-serif;white-space:pre-wrap">    aStyleName.Append( OUString::valueOf( static_cast<sal_Int32>( nDepth ) ) );</span></div>

<div style><span style="font-family:arial,helvetica,sans-serif;white-space:pre-wrap"><br></span></div><div style><font face="arial, helvetica, sans-serif">which is the integer case. Similar problems apply to the char and bool cases.</font></div>

<div style><br></div><div style>The purpose of these methods is purely to reduce this boilerplate coding and increase readability, so that we have:<br></div><div style><br></div><div style><div><span style="font-family:arial,helvetica,sans-serif;white-space:pre-wrap">    aStyleName.Append( OUString::valueOfInt(  nDepth ) );</span></div>

<div><span style="font-family:arial,helvetica,sans-serif;white-space:pre-wrap"><br></span></div></div><div style>Given that our string classes are used pretty much everywhere, having a wide API that increases readability can only be a good thing.</div>

<div style><br></div><div style>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.</div>

<div style>Sometimes, we have to work with what we have.</div><div style><br></div><div style><br></div></div></div></div>