On Tue, 27 Jul 2004 23:09:37 -0400, Ben Hinkle wrote:
> Personally I think
> char[]/std.string is better than a class

Why?  The only member variable of a class need be is a char[] (or perhaps dchar[] or wchar[] if needed) so it can't be a memory size or efficiency issue.  A String is like the perfect, textbook object, so what's the procedural method got over it?

I know it's a hack, but I wonder if making the compiler able to implicitly convert between a String class and char[]'s would be a desirable feature.? In Java, the String class is a special class. Just thinking out loud.

John

Ben Hinkle wrote:
> parabolis wrote:
> 
> 
>>Arcane Jill wrote:
>>
>>
>>>In article <ce6elp$2jmu$1@digitaldaemon.com>, parabolis says...
>>>
>>>
>>>
>>>>I have a feeling that D will eventually have a String class of its
>>>>own as it currently has no String functionality at all.
>>>
>>>
>>>I believe Hauke is working on that string class.
>>
>>This could be good to hear.
> 
> 
> I don't know if archives of the old newsgroup are around but I recall a long
> thread about string classes back then (at least I think it was on the old
> newsgroup). It might be worth looking at those posts. Personally I think
> char[]/std.string is better than a class and is certainly better to choose
> one or the other but not both.
> 
> 

If you are interested please read my post towards the end of the  previous thread OT - scanf in Java. Especially the end of the post where I discuss the benefits of a class and/or class+interface approach.

In article <ce75di$2roa$1@digitaldaemon.com>, Ben Hinkle says...

>Personally I think
>char[]/std.string is better than a class and is certainly better to choose
>one or the other but not both.

The string class concept came up more recently in a discussion of internationalization issues, transcoding issues, etc., and would, I think, be geared toward that end.

But even without that, there are good reasons for a string class. Consider:

#    char[] s = new char[2];
#    char[0] = 0x80;
#    char[0] = 0x81;

Whoa! - that's invalid UTF-8 - but when is it going to be spotted? When will that manifest as a bug? With a class, you can have Design by Contract - a class invariant would have spotted that straight away.

Just one thought among many. Personally I don't care how it's done, but I am pleased to hear that transcoding etc. is being worked upon, and if that results in a string class, so be it.

Arcane Jill

Yes, a string class would be cool. I think there is a major difference between char[] and String (class) which would not make them interfere.

I wonder whether there's much sense in creating an analogous class to StringBuffer - which would really interfere with char[] in use.

String as a class could, as opposed to char[]:
- be immutable, thus somewhat safer
- try to check for legality
- can be abstract with descendants being in UTF8/16/32/ some other representations
- allow some intuitive processing
- take care of some conversions
- overload comparison operators
...

Naturally, one wouldn't want to write algorithms to work with an immutable class, but they can work with basic data types and nonthless input and output a String without a performance penalty.

Arcane Jill schrieb:

> In article <ce75di$2roa$1@digitaldaemon.com>, Ben Hinkle says...
> 
> 
>>Personally I think
>>char[]/std.string is better than a class and is certainly better to choose
>>one or the other but not both.
> 
> 
> The string class concept came up more recently in a discussion of
> internationalization issues, transcoding issues, etc., and would, I think, be
> geared toward that end.
> 
> But even without that, there are good reasons for a string class. Consider:
> 
> #    char[] s = new char[2];
> #    char[0] = 0x80;
> #    char[0] = 0x81;
> 
> Whoa! - that's invalid UTF-8 - but when is it going to be spotted? When will
> that manifest as a bug? With a class, you can have Design by Contract - a class
> invariant would have spotted that straight away.
> 
> Just one thought among many. Personally I don't care how it's done, but I am
> pleased to hear that transcoding etc. is being worked upon, and if that results
> in a string class, so be it.
> 
> Arcane Jill
> 
> 

Ilya Minkov wrote:
> 
> String as a class could, as opposed to char[]:
> - be immutable, thus somewhat safer
> - try to check for legality
> - can be abstract with descendants being in UTF8/16/32/ some other representations
> - allow some intuitive processing
> - take care of some conversions
> - overload comparison operators
> ...
> 
> Naturally, one wouldn't want to write algorithms to work with an immutable class, but they can work with basic data types and nonthless input and output a String without a performance penalty.

Actually I agree with almost all the benifits you list. However I do not clearly understand all the issues behind why Java choose to make String immutable and so I am not really very clear on all the benefits of an immutable String class. I know it makes substring() much simpler because it is safe to return a String pointing into another String.

However it sounds like they have a StringTable data structure that may offer other benefits as well. Do you know much about how they implemented StringTable?

stonecobra wrote:

> I will release it, I just worry about releasing something that doesn't even work.  Are any of you willing to help me make it better?

So, no one is interested in it?  I won't release it then.

Thanks
Scott Sanders