February 20, 2005
Derek wrote:

> 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.

Well, it's not a bad thing if you actually *want* the method on Object.
(assuming for a second that the current D method of separating methods
that return different types by a suffix, is a satisfactory workaround)

However, it does become a problem when it includes oldskool C functions
with a high abuse factor (like printf) or methods whose implementations
drag a lot of extra overhead into the D runtime library (like print)...

And, of course, adding "bool" to object.d is just a traditional Hack. :)

--anders
February 20, 2005
> 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?

If the programmer needs to be explicit about it, isn't it just the same if you use two method names? :)


xs0
February 20, 2005
Brad Anderson wrote:
| Anders F Björklund wrote:
|
|>
|> IMHO, the method that really needs to die in Object is "print()"
|
| amen.

Let the hunting season begin!

Thomas

February 20, 2005
uframer wrote:
| Oh, i'm tired of these chars(char wchar dchar).Why can't we just have
"one"
| standard codepage, just like what java does?

What are the standard char types for Windows and Linux APIs?

Thomas
February 20, 2005
On Sun, 20 Feb 2005 21:43:59 +0100, Anders F Björklund wrote:

[snip]

> 
> None of these are really issues for removing Object.toString. (first one can use .toString, second can use char[] toString)

Unless one wants to code 'dchar[]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.

Yes, I think this is the crux of the reason that toString() is in Object. However, it is only partially achieving this aim, because the output, a char[], is still an UTF8 stream and will only fully display correctly on devices that understand UTF8 streams. However, as most of us only deal with English or simple Latin characters, this is not a big deal; pity about the other poor buggers ;-)

I now realize that if I want to 'override' the return type in D, I need to place the return type information into the function name, like toUTF8, toUTF16, toUTF32.

-- 
Derek
Melbourne, Australia
February 20, 2005
Thomas Kühne wrote:

> What are the standard char types for Windows and Linux APIs?

"wchar_t". They just differ on the implementation ;-)
(in Phobos, it is located in std.c.stddef, by the way)

A lot of of the legacy API just use "char", however...
Which can be of any sign and any encoding, basically?

--anders
February 20, 2005
On Sun, 20 Feb 2005 16:09:45 +0100, Anders F Björklund wrote:

> Derek wrote:
> 
>>>Why can't you just use char[] toString() with std.utf.toUTF8 ?
>> 
>> I assume you mean I can code ...
>> 
>>     x = std.utf.toUTF32( myClass.toString() );
>> 
>> Of course I can, but that's not the point.
> 
> Okay, then I missed the point...

That's okay. The point is, I wanted to use a function name that just happened to be in Object, but with a different return type. So Walter's choice of a specific function name has prevented anyone else using the same name with a different return type.

> Do you want to override
> methods with different return types ?

Yes, but that is not the point either. The point is, to reword it yet again, Walter has cut off a set of method names; they are no longer available to be *freely* used by other class authors.

The name 'toString' is just an example. I'm not actually talking about what toString() does or does not do. It is just an example of this situation.

>Or do you just wish
> that D should default to UTF-32 instead of UTF-8 like now ?

I could live with that. For external storage UTF8 or UTF16 would be better, but for character manipulation, UTF32 is safer at the expense of extra RAM usage (IMHO).

-- 
Derek
Melbourne, Australia
February 20, 2005
Derek wrote:

> However, it is only partially achieving this aim, because the output, a
> char[], is still an UTF8 stream and will only fully display correctly on
> devices that understand UTF8 streams. However, as most of us only deal with
> English or simple Latin characters, this is not a big deal; pity about the
> other poor buggers ;-)

D *only* supports input and output in UTF formats, so you'll have
to catch up with the rest of us I'm afraid... (by using Unicode)

It's possible to convert char[] into ubyte[] for legacy displays,
but it's not something that's in the main language/lib by itself.

There's decent support for wchar[] functions, if in the OS:
See http://www.digitalmars.com/techtips/windows_utf.html

> I now realize that if I want to 'override' the return type in D, I need to
> place the return type information into the function name, like toUTF8,
> toUTF16, toUTF32.

Yup, that's how it works at the moment. "W" is a popular suffix for
wchar[] versions of the char[] ones. It's either "Wide" or "Walter" :-)

--anders
February 20, 2005
Derek wrote:

>Okay, then I missed the point... 
> 
> That's okay. The point is, I wanted to use a function name that just
> happened to be in Object, but with a different return type. So Walter's
> choice of a specific function name has prevented anyone else using the same
> name with a different return type.

Right.
I was used to both, from Java (no return overloads, has Object.toString:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#toString())

> I could live with that. For external storage UTF8 or UTF16 would be better,
> but for character manipulation, UTF32 is safer at the expense of extra RAM
> usage (IMHO).

No argument there. (many functions in D uses a "char[]" / "dchar" combo,
UTF-8 for storage and UTF-32 for looping and outputting characters, etc)

--anders
February 20, 2005
In article <105fk737tg8h1.4qbrn36dqke$.dlg@40tude.net>, Derek says...
>
>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'.

I meant for example,
# class Foo {
#   char[] toUTF8(){ return "value 1"; }
#   ... // imagine thousands of lines between toUTF8 and toUTF16
#       // that evolved over the years
#   wchar[] toUTF16(){ return "value 2 not value 1"; }
# }