In article <cvajck$75n$1@digitaldaemon.com>, Chris Sauls says...
>>What I'd personally like to see is something similar to what Sofu's Value class exposes. It could still 'default' to class name.
>># class Object {
># // ...
># char[] toUTF8() { return this.classinfo.name; }
># wchar[] toUTF16() { return .toUTF16(this.toUTF8()); }
># dchar[] toUTF32() { return .toUTF32(this.toUTF8()); }
># // ...
># }
>>But maybe I'm crazy.
>>-- Chris S
What is Sofu?
One issue with having all three functions in Object is that the class author has
to make sure they don't return different values from the three versions. That
looks like it will be a source of bugs and confusion. Plus it makes the API
surface area larger. Maybe we just need to add
wchar toWString(Object o){ return toUTF16(o.toString()); }
dchar toDString(Object o){ return toUTF32(o.toString()); }
to std.string. That way class authors don't have to worry about which the user
wants to use in the end.
Let me add, though, that std.string defines things like toString(int x) and
toString(double x) and it would be a waste IMO to have two more versions of all
of those just to save people from typing toUTF16 or toUTF32.
-Ben

On Sun, 20 Feb 2005 12:07:39 -0500, Jarrett Billingsley wrote:
>> can you please confirm or deny that 'char[] toString()' will be removed from the Object class. And if so, when?
> > Am I REALLY this invisible??!
> > I just posted the SAME THREAD yesterday! Yes, in fact, it's two down from this one!
No, I think the topic just has to be brought up over and over again before something is done about it. The more it's brought up by different people, the better, I guess.
Nobody's out to ignore you personally. ;-)

Ben Hinkle wrote:
> What is Sofu?
Sofu is a textual data file format. It has its uses.
http://sofu.sourceforge.net/index.html> One issue with having all three functions in Object is that the class author has
> to make sure they don't return different values from the three versions.
Note that in my example, Object.toUTF16() and Object.toUTF32() just transcode and return the result of Object.toUTF8() -- my point? If I just need basic functionality for my class's toUTF*() then I only have to override one function.
-- Chris S

Ben Hinkle schrieb:
> What is Sofu?
A parser library for a data file format. http://sofu.sourceforge.net/
Still quite half-baked, I need to get some time to work on it again. :)
> Let me add, though, that std.string defines things like toString(int x) and toString(double x) and it would be a waste IMO to have two more versions of all of those just to save people from typing toUTF16 or toUTF32.
In applications that use wchar[] or dchar[] as the default in many places, additional toUTF*() calls can obfuscate the code considerably. Also, I think that wchar[] is probably the most efficient format for most strings. Just think of CJK languages. IIRC, their characters usually take up three code units in UTF-8 - more than in UTF-16. Add to that the fact that in the very near future most people using a computer will be Chinese...
-Sebastian

Jarrett Billingsley wrote:
> Am I REALLY this invisible??!
> > I just posted the SAME THREAD yesterday! Yes, in fact, it's two down from this one!
No, it's not the same question... (even without the yelling)
You asked: ("Remove Object.toString()?")
> will Object.toString() be removed? The same information is available through Object.classinfo.name, and it's really irritating to have to type "std.string.toString" every time I want to use toString() in a class member function.
Derek asked: ("toString in Object")
> can you please confirm or deny that 'char[] toString()' will be removed
> from the Object class. And if so, when?
> > Because it exists, I cannot create a 'dchar[] toString()' in my classes, as
> I get the dreaded "overrides but is not covariant with
> object.Object.toString" message!
None of these are really issues for removing Object.toString.
(first one can use .toString, second can use char[] toString)
I also think that toString() is *supposed* to return something
readable, like it works in Java. And std.format seems to agree:
> case Mangle.Tclass:
> vobject = va_arg!(Object)(argptr);
> s = vobject.toString();
> goto Lputstr;
That the default implementation doesn't, that's another issue...
And better Phobos documentation would definitely be a big help.
http://www.digitalmars.com/d/phobos.html:
> class Object
> All class objects in D inherit from Object.
> char[] toString()
> Convert Object to a human readable string.
Splitting toString into toUTF8/toUTF16/toUTF32 could of course
be done, if performance is ever needed on the toString method ?
--anders

On Sun, 20 Feb 2005 20:00:24 +0000 (UTC), Ben Hinkle <Ben_member@pathlink.com> wrote:
> In article <cvajck$75n$1@digitaldaemon.com>, Chris Sauls says...
>>>> What I'd personally like to see is something similar to what Sofu's
>> Value class exposes. It could still 'default' to class name.
>>>> # class Object {
>> # // ...
>> # char[] toUTF8() { return this.classinfo.name; }
>> # wchar[] toUTF16() { return .toUTF16(this.toUTF8()); }
>> # dchar[] toUTF32() { return .toUTF32(this.toUTF8()); }
>> # // ...
>> # }
>>>> But maybe I'm crazy.
>>>> -- Chris S
>> What is Sofu?
> One issue with having all three functions in Object is that the class author has
> to make sure they don't return different values from the three versions. That
> looks like it will be a source of bugs and confusion. Plus it makes the API
> surface area larger.
I agree, yuck.
> Maybe we just need to add
> wchar toWString(Object o){ return toUTF16(o.toString()); }
> dchar toDString(Object o){ return toUTF32(o.toString()); }
> to std.string. That way class authors don't have to worry about which the user
> wants to use in the end.
It's a pity we can't overload on return type. Or can we.. if we force the programmer to be explicit about it? It would require return type to be considered in the name resolution system.. perhaps it's too big a change?
> Let me add, though, that std.string defines things like toString(int x) and
> toString(double x) and it would be a waste IMO to have two more versions of all
> of those just to save people from typing toUTF16 or toUTF32.
Agreed, they simply need to type:
double d;
dchar[] s;
s = toUTF32(toString(d));
or, if we add "explicit transcoding" on cast:
double d;
dchar[] s;
s = cast(dchar[])toString(d);
or, if we add overload on return type:
double d;
dchar[] s;
s = toString(d);
Regan

On Sun, 20 Feb 2005 12:07:39 -0500, Jarrett Billingsley wrote:
>> can you please confirm or deny that 'char[] toString()' will be removed from the Object class. And if so, when?
> > Am I REALLY this invisible??!
Alternately, it could be that I didn't read your post before sending mine. I note that there is a mere 2 hour difference between the two posts - so like the old saying goes "great minds think alike" ;-)
But I'm more than happy to acknowledge that you were the first raiser of this issue - I don't need the glory ;-)
> I just posted the SAME THREAD yesterday! Yes, in fact, it's two down from this one!
However, I do notice that the reasons for posting the similar messages are different. You are wanting to avoid having to specify the complete package.module name to disambiguate the toString() references, whereas I was wanting to create a version of toString() that returned dchar[] rather than char[].
I then when on to realize that *any* function that is declared in Object will prevent a same-named function in any another class from returning a different data type. And it is debatable whether that is such a good thing.
--
Derek
Melbourne, Australia

Sebastian Beschke wrote:
> In applications that use wchar[] or dchar[] as the default in many
> places, additional toUTF*() calls can obfuscate the code considerably.
> Also, I think that wchar[] is probably the most efficient format for
> most strings.
Java and Windows seem to agree with you... Walter, however, does not.
> Just think of CJK languages. IIRC, their characters
> usually take up three code units in UTF-8 - more than in UTF-16. Add to
> that the fact that in the very near future most people using a computer
> will be Chinese...
Well, it would still *work* with Chinese which is a (small) comfort ?
And it does get a little silly after a while with "full" support...
int mainUTF8(char[][] args)
{
}
int mainUTF16(wchar[][] args)
{
}
int mainUTF32(dchar[][] args)
{
}
It's a lot easier to just live with char[], even if it's "slower".
Note: DMD and Phobos also convert UTF-16 and UTF-32 to UTF-8 internally,
in a lot of places. Sensitive areas have all three versions overloaded.
--anders

On Sun, 20 Feb 2005 20:00:24 +0000 (UTC), Ben Hinkle wrote:
> In article <cvajck$75n$1@digitaldaemon.com>, Chris Sauls says...
>>>>What I'd personally like to see is something similar to what Sofu's Value class exposes. It could still 'default' to class name.
>>>># class Object {
>># // ...
>># char[] toUTF8() { return this.classinfo.name; }
>># wchar[] toUTF16() { return .toUTF16(this.toUTF8()); }
>># dchar[] toUTF32() { return .toUTF32(this.toUTF8()); }
>># // ...
>># }
>>>>But maybe I'm crazy.
>>>>-- Chris S
> > What is Sofu?
> One issue with having all three functions in Object is that the class author has
> to make sure they don't return different values from the three versions. That
> looks like it will be a source of bugs and confusion.
On the other hand, names like "toUTF16" and "toUTF32" specify the return data type in the name itself. So it is unlikely that coders would be confused enough to write a toUTF16 function that returned a 'real'.
> Plus it makes the API
> surface area larger. Maybe we just need to add
> wchar toWString(Object o){ return toUTF16(o.toString()); }
> dchar toDString(Object o){ return toUTF32(o.toString()); }
> to std.string. That way class authors don't have to worry about which the user
> wants to use in the end.
Now this argument has some weight.
--
Derek
Melbourne, Australia