toString vs. toUtf8
Steven Schveighoffer
schveiguy at yahoo.com
Mon Nov 19 14:53:01 PST 2007
"Sean Kelly" wrote
> Steven Schveighoffer wrote:
>> "Sean Kelly" wrote
>>> What I discovered during a test conversion of Tango was that converting
>>> all uses of toUtf8 to toString /except/ those intended to perfom UTF
>>> conversions reduced code clarity, and left me unsure as to which name I
>>> would actually use in a given situation. For example, there is quite a
>>> bit of code in the text and io packages which convert an arbitrary type
>>> to a char[] for output, etc. So by making this change I was left with
>>> some conversions using toString and others using toUtf8, toUtf16, and
>>> toUtf32, not to mention the fromXxx versions of these same functions. As
>>> this is template code, the choice between toString and toUtf8 in a given
>>> situation was unclear.
>>
>> Can you give an example file for this problem? It would be easier to
>> understand your problem if I knew exactly what you were talking about.
>> An actual example is fine, it doesn't need to be minimized (i.e. "take a
>> look at tango/io/X.d")
>
> tango.text.convert.Layout
I can't say I see a problem.
I'd say use toUtf8 when doing a conversion from one type of encoded string
to another (i.e. utf-16 to utf-8), and use toString when overriding Object's
toString, OR when converting a native type (i.e. int, float, etc). For
example tango.text.convert.Integer.toUtf8 should be toString.
In the case of tango.text.convert.Layout, I don't see any overriding of
Object.toUtf8? The Unicode.toUtf8 should be left alone since it is a
conversion between utf encodings. In any case, Unicode.toUtf8 is a global
function, and is not overriding Object.toUtf8, so there is no conflict
there.
-Steve
More information about the Digitalmars-d
mailing list