Heinz wrote:
<snip>
> Thanks guys for your answers. I know it is a basic stuff, i used to work with
> char[] in lower level languages but now i was used to the string type in managed
> languages.
> 
> I'll use an alias for now but hope Walter to add a string type in phobos.

http://www.digitalmars.com/d/builtin.html

"But after all, what is a string if not an array of characters? If the builtin array problems are fixed, doesn't that resolve the string problems as well? It does. It seems odd at first that D doesn't have a string class, but since manipulating strings is nothing more than manipulating arrays of characters, if arrays work, there's nothing a class adds to it."

Stewart.

I'm a late entrant on this discussion, but I've only just gotten on the D band wagon . . .

I think adding a string type has some serious merit. Namely:

1. "string" is a lot easier on the eyes than "char[]", to me at least. Especially when being used in an associative array:

int[char[]] arr;

versus

int[string] arr;

2. string-specific functions can be added to the string type. I'm a complete D noob so forgive any misinformation here. Currently I understand there to be a separate module for string-related functions. To me, there should be a string type that defines those functions:

char[] upper = toupper(myString);

versus:

string upper = myString.toupper();

The latter seems like much better OO design to me. Side note: I don't understand the namng of "toupper" as opposed to "toUpper" - isn't camel-casing the norm in D?

Now arguably developers could just typedef or alias char[] as string and be done with it. But this doesn't address my second point.

Or they could develop their own string class and be done with it. But this means that almost every decent-sized D project will have its own string implementation. Obviously not good.

Regards,
Kent Boogaart


In article <e7oki3$2pfe$1@digitaldaemon.com>, Stewart Gordon says...
>
>Heinz wrote:
><snip>
>> Thanks guys for your answers. I know it is a basic stuff, i used to work with char[] in lower level languages but now i was used to the string type in managed languages.
>> 
>> I'll use an alias for now but hope Walter to add a string type in phobos.
>
>http://www.digitalmars.com/d/builtin.html
>
>"But after all, what is a string if not an array of characters? If the builtin array problems are fixed, doesn't that resolve the string problems as well? It does. It seems odd at first that D doesn't have a string class, but since manipulating strings is nothing more than manipulating arrays of characters, if arrays work, there's nothing a class adds to it."
>
>Stewart.

Kent Boogaart wrote:

> 2. string-specific functions can be added to the string type. I'm a complete D
> noob so forgive any misinformation here. Currently I understand there to be a
> separate module for string-related functions. To me, there should be a string
> type that defines those functions:
> 
> char[] upper = toupper(myString);
> 
> versus:
> 
> string upper = myString.toupper();

You can do that now:

char[] myString = "myString";
cahr[] upper = myString.toupper();

> 
> The latter seems like much better OO design to me. 

Don't forget that D supports the procedural programming paradigm as well. Object Orientation has benefits, but is not a panacea. In my opinion, it shouldn't matter whether or not standard library APIs use OO design priniciples, as it generally does not affect the design of user code. Besides which, OO does not necessarily mean 'classes'. There are plenty of free function APIs that follow the OO paradigm. OpenGL is a great example. IMO, the need for a string class in D is imaginary. I have no use for one.

Kent Boogaart wrote:
<snip>
> Or they could develop their own string class and be done with it. But this means
> that almost every decent-sized D project will have its own string
> implementation. Obviously not good.
<snip top of upside-down reply>

Only if nearly every D programmer is an OO purist.

http://www.digitalmars.com/d/overview.html
"Who D is Not For"
"Language purists. D is a practical language, and each feature of it is evaluated in that light, rather than by an ideal. For example, D has constructs and semantics that virtually eliminate the need for pointers for ordinary tasks. But pointers are still there, because sometimes the rules need to be broken. Similarly, casts are still there for those times when the typing system needs to be overridden."

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.