www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The String Class

reply Ant <Ant_member pathlink.com> writes:
It's becoming evident that "every body" will have it's own
implementation of a String class.

Walter,
it's time to add "The String Class" to phobos,
as simple as it might be. It doesn't have to be a class, actually
an interface might be a better idea.
That way all other implementations would extend on the 'official' one
so there would be a common ground for a String class on every library
making all libs communicate at least the very common String object
between each other.

I could grab all the functions from the phobos string module and package
them as an interface or package them as an Abstract class
or a (concret class) - just say the word.

once Walter said he couldn't imagine a use for extending a String class,
(neither can Sun as the java String class is final),
on the next release of dool the Path class will extend the String class.
Is that a good idea? it's looking good to me for the last 3 days...
Strings on dool are not imutable.

Ant
Nov 24 2004
next sibling parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Ant schrieb am Wed, 24 Nov 2004 17:17:00 +0000 (UTC):
 It's becoming evident that "every body" will have it's own
 implementation of a String class.

 Walter,
 it's time to add "The String Class" to phobos,
 as simple as it might be. It doesn't have to be a class, actually
 an interface might be a better idea.
 That way all other implementations would extend on the 'official' one
 so there would be a common ground for a String class on every library
 making all libs communicate at least the very common String object
 between each other.

Maybe an interface might be useful indeed. Pleas keep in mind that much of the "String" fuss results from the simple fact that Linux, Windows and WindowsNT use different native "char" sizes. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.9 (GNU/Linux) iD4DBQFBpMZP3w+/yD4P9tIRArdaAJ93JC6jR+lVwdjbmiQ/8sFn8uG5rwCWOKXY RFcmoyjjKXKHVs1rF7BrEw== =kF+4 -----END PGP SIGNATURE-----
Nov 24 2004
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
In article <co2fmc$28h1$1 digitaldaemon.com>, Ant says...

it's time to add "The String Class" to phobos,
as simple as it might be. It doesn't have to be a class, actually
an interface might be a better idea.

(Please excuse my limited vision.) This should be extended to all common needs of a modern runtime lib. including database access, for instance. There is a project on dsource to provide database access. dool contains a functional database access with implementations to SQLite3 and PostreSQL (And I also have a GUI (DUI) client interface). I call the D users that believe that they can come up with a library better then I can (actually they can't, they can only talk about it) to forget the implementation and just give us a common ground so that D libs can take one single direction - even with if multiple paths will be available. So Lars Ivar, Matthew, Charles,... what do you thing? just give is the interface we'll do the hard work. (of course I'll ignore any non OO ideas.) But the String class should still go ahead as soon as possible, as it is a simple and obvious thing to do. Ant
Nov 24 2004
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ant wrote:

 Strings on dool are not imutable.

Why not? Doesn't that just add synchronization overhead ? Both D's char[] and Java's String are both immutable (copy-on-write), using a new [] array or StringBuffer when they need to modified by a function or something. http://www.digitalmars.com/d/memory.html#copyonwrite --anders
Nov 24 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <co2k32$2evj$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Ant wrote:

 Strings on dool are not imutable.

Why not? Doesn't that just add synchronization overhead ?

no, also adds flexibility and efficiency when no synchronization is necessary. responsability is passed to the application. I don't see a difference between strings and other objects, the problems and solutions are the same.
Both D's char[] and Java's String are both immutable
(copy-on-write), using a new [] array or StringBuffer
when they need to modified by a function or something.

http://www.digitalmars.com/d/memory.html#copyonwrite

thank you for the link, I reread it. I'll check if there is any efficiency problems with dool String. It's mostly repackaging phobos string module. Ant
Nov 24 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ant wrote:

Doesn't that just add synchronization overhead ?

no, also adds flexibility and efficiency when no synchronization is necessary. responsability is passed to the application. I don't see a difference between strings and other objects, the problems and solutions are the same.

I just meant that immutable objects are by their very definition thread-safe... Mutable objects aren't, so they can't be shared as easily between threads ? And there is also the: "who owns the string" issue, discussed in copy-on-write BTW: Objective-C has a neat implementation where NSMutableString extends NSString (immutable) --anders
Nov 24 2004
parent Ant <Ant_member pathlink.com> writes:
In article <co2m0t$2ii9$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

BTW:
Objective-C has a neat implementation where
NSMutableString extends NSString (immutable)

The obvious solution, I thought of that and actually start to code it, but I have absolutly no need to add work to my projects. If somebody want's it on dool implementations are welcome. current solution on dool is to "copy-on-fear": String s = new String("There"); //... writefln(s.dup.prepend("Hello ")); that actually is kind of bad because .dup will create a new String and char[] and prepend another char[] - but that's what I'm doing for now. Ant (I'm not sure writef can print just the object or needs a format string)
Nov 24 2004
prev sibling parent reply "Kris" <fu bar.com> writes:
"Anders F Björklund" <afb algonet.se> wrote
| Ant wrote:
|
| > Strings on dool are not imutable.
|
| Why not?
| Doesn't that just add synchronization overhead ?
|
| Both D's char[] and Java's String are both immutable
| (copy-on-write), using a new [] array or StringBuffer
| when they need to modified by a function or something.
|
| http://www.digitalmars.com/d/memory.html#copyonwrite
|


The value of immutable (read-only) objects is rarely seen until one brings
multiple threads into the mix. At that point, immutability can, and does,
provide enormous benefit in terms of robustness and performance. It's hard
to quantify just how valuable that can be.

In Mango (for example) there's often an immutable base-class plus a mutable
derivative. This allows for both to be passed as the read-only version,
whilst maintaining control over who get to modify something, whilst avoiding
synchronized (and its additional try/catch overhead).

Mango.icu takes the same approach with UString, which is the mutable
derivative of the (read only) UText class.

I fully agree with Antonio, that a String class is both entirely useful and
should be part of the D library specification (as an Interface). Of course,
they are especially useful when it comes to unicode, for the obvious
reasons. I also agree with Antonio's perspective on OO within libraries. The
functional approach is exemplified rather nicely by Phobos, and it is
welcome to remain there :-)

As far as splintering of String implementation goes, I had hoped the Ares
'group' would have done something within that realm. That has not yet
happened, so I'm tempted to suggest that Antonio and I (and whomever else)
strive to ensure our libraries are compatible with each other at the
Interface level (where there's related functionality). After all, it's to
the benefit of everyone if common APIs converge.

How about it?

BTW; this kind of nagging problem is what
http://www.dsource.org/forums/viewforum.php?f=31 was intended to resolve. I
know that Sean has been fervently working on some of the initial issues
there, but I gather he's the only one; and Walter's help is needed on a
couple of small but important issues there. The ICU wrappers were intended
to be submitted to that group for consideration as one of the 'peripheral'
libraries. Perhaps we can revitalize that effort? Perhaps Antonio would be
willing to join in? Perhaps Walter will apply a day or two of his time to
resolve those little issues, so the Ares group can move forward again?
Perhaps someone will bring a guitar along and sing encouraging folk-songs
too ;-)
Nov 24 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <co2nin$2l5l$1 digitaldaemon.com>, Kris says...
BTW; this kind of nagging problem is what
http://www.dsource.org/forums/viewforum.php?f=31 was intended to resolve. I
know that Sean has been fervently working on some of the initial issues
there, but I gather he's the only one; and Walter's help is needed on a
couple of small but important issues there. The ICU wrappers were intended
to be submitted to that group for consideration as one of the 'peripheral'
libraries. Perhaps we can revitalize that effort? Perhaps Antonio would be
willing to join in? Perhaps Walter will apply a day or two of his time to
resolve those little issues, so the Ares group can move forward again?
Perhaps someone will bring a guitar along and sing encouraging folk-songs
too ;-)

If people are interested in the Ares project, please post there. I'm focused on sorting out low-level design issues and would welcome suggestions--I've mostly been talking to people about this stuff offline since the Ares forum has gone silent. As for a string class or anything else you all can think of, that might be a good forum for such discussions as well. Sean
Nov 24 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <co2nin$2l5l$1 digitaldaemon.com>, Kris says...

 I'm tempted to suggest that Antonio and I (and whomever else)
strive to ensure our libraries are compatible with each other at the
Interface level

I've try to reply to this but it seems I have only one thing to say: "Let's do it". "Our" Libraries is the key word. We have the code, we should strive to make it compatible. I didn't know about Ares so you say if we should take over, join or ignore it. First suggestion: let's keep it simple and pragmatic, this thing can grow but only if it has roots. If we aim to the moon will never get of the ground. We are smart enough to allow it room to grow on the original design. Second suggestion: you say where we should meet. Say it here and let's move the discussion there. finally, about DM: all we can ask to DM is that if an overlaping project is born that it be release as soon as possible, as incomplete as possible. Ant So many metaphors! This is how they talk in North America (Both US and Canada) I allways thought it's a limited and deficient way to express a thought - the way they use it.
Nov 24 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <co2upv$2vl1$1 digitaldaemon.com>, Ant says...

I didn't know about Ares so you say if we should take over, join
or ignore it.

Ok, I looked at a couple of posts on Ares: let's invite Ares to join our new project. Ares it's a lib at the same level as our's. In other words, let's ignore it. Ant
Nov 24 2004
prev sibling parent "Kris" <fu bar.com> writes:
Hey Antonio;

Then I'll suggest that we take advantage of what already^H^H^H^H^H^H almost
happened over at dsource :-)

See ya over there!


"Ant" <Ant_member pathlink.com> wrote in message
news:co2upv$2vl1$1 digitaldaemon.com...
| In article <co2nin$2l5l$1 digitaldaemon.com>, Kris says...
| >
|
| > I'm tempted to suggest that Antonio and I (and whomever else)
| >strive to ensure our libraries are compatible with each other at the
| >Interface level
|
| I've try to reply to this but it seems I have only one thing to say:
| "Let's do it".
| "Our" Libraries is the key word. We have the code, we should strive to
| make it compatible.
|
| I didn't know about Ares so you say if we should take over, join
| or ignore it.
|
| First suggestion: let's keep it simple and pragmatic, this thing can
| grow but only if it has roots. If we aim to the moon will never get
| of the ground. We are smart enough to allow it room to grow
| on the original design.
|
| Second suggestion: you say where we should meet. Say it here
| and let's move the discussion there.
|
| finally, about DM: all we can ask to DM is that if an overlaping
| project is born that it be release as soon as possible,
| as incomplete as possible.
|
| Ant
|
| So many metaphors! This is how they talk in North America
| (Both US and Canada) I allways thought it's a limited and deficient
| way to express a thought - the way they use it.
|
|
Nov 24 2004
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <co2fmc$28h1$1 digitaldaemon.com>, Ant says...
It's becoming evident that "every body" will have it's own
implementation of a String class.

If "every body" means "some people" then I agree. I personally have no intention of using a string class, nor do I see the need for one. But perhaps I'm in the minority on this issue. Sean
Nov 24 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:co2lti$2idl$1 digitaldaemon.com...
 In article <co2fmc$28h1$1 digitaldaemon.com>, Ant says...
It's becoming evident that "every body" will have it's own
implementation of a String class.

If "every body" means "some people" then I agree. I personally have no intention of using a string class, nor do I see the need for one. But

 I'm in the minority on this issue.


 Sean

I expect you (and I) are in the "silent majority".
Nov 24 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

It's becoming evident that "every body" will have it's own
implementation of a String class.

If "every body" means "some people" then I agree. I personally have no intention of using a string class, nor do I see the need for one. But perhaps I'm in the minority on this issue.

I expect you (and I) are in the "silent majority".

Maybe someone can sum up what String has, that char[] doesn't ? (besides a nicer name, which can easilly be "fixed" with an alias) I'm familiar with extremes: C's (char *) and Java's String objects, just wondered why one should make the base D language require OOP... Doesn't it just duplicate C++ std::strings? http://www.digitalmars.com/d/cppstrings.html I think I prefer the built-in type, myself. So I'm "minority" too. Although it's probably good to have *one* wrapper class, and not 42. --anders
Nov 24 2004
parent "Kris" <fu bar.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:co2p94$2nfn$1 digitaldaemon.com...
| Ben Hinkle wrote:
|
| >>>It's becoming evident that "every body" will have it's own
| >>>implementation of a String class.
| >>
| >>If "every body" means "some people" then I agree.  I personally have no
| >>intention of using a string class, nor do I see the need for one.
| >>
| >> But perhaps I'm in the minority on this issue.
| >
| > I expect you (and I) are in the "silent majority".
|
| Maybe someone can sum up what String has, that char[] doesn't ?
| (besides a nicer name, which can easilly be "fixed" with an alias)
|
| I'm familiar with extremes: C's (char *) and Java's String objects,
| just wondered why one should make the base D language require OOP...
|
| Doesn't it just duplicate C++ std::strings?
| http://www.digitalmars.com/d/cppstrings.html
|
| I think I prefer the built-in type, myself. So I'm "minority" too.
| Although it's probably good to have *one* wrapper class, and not 42.
|
| --anders



(this is a general post: it is not directed toward Anders, Sean, Ben, or
anyone else).


I don't think anyone was trying to say "it's OO or nothing" here ... I mean,
one doesn't have to /use/ a String class if they don't wish to :-)

All that's being said (I think) is that some folks appreciate the notion and
convenience of such a class, and it would be advantageous to all those (who
care) if there were some kind of 'standard' String class (or perhaps
Interface).

One could be forgiven for assuming the Functional Liberation Front were
being oppressed or something (cue Monty Python: "help! help! I'm being
repressed!!").

Personally, I use char[] and void[] for a lot of things. You'll find them
spread liberally throughout ~60,000 lines of D code I've written. However,
there is a segment of the population out there who appreciate a
representation at a somewhat higher level. This is particularly true when
the going gets rough (such as with unicode). Isn't it nice to have the
option of using a wrapper around all that nonsense without having to
understand and code it all yourself? Additionally, having a class that
implements COW allows one to just get on and not worry about it anymore.
Having a standard String allows one to potentially converse across libraries
from multiple independent sources (if the authors found it's worthwhile to
be string-enabled).

Therein lies the benefit; and that is what, for instance, the ICU-enabled
UString has been made available for. It just makes life easier for those who
/choose/ to use it, and it's there as a potential fulcrum for further
libraries that deal with unicode.
Nov 24 2004
prev sibling next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
Well, actually i have been very happy with char[] until now.
How about providing a standard alias like:
alias char[] string; //or String
and a bunch of usefull methods like:
void someOp(string str, int bla)
{
    //do something with stri and bla
}
and then use it in a class-like way:
string bla;
bla.someOp(5);

I generally am for the OO design of libs but don't see the need
for D strings to be OO.

"Ant" <Ant_member pathlink.com> wrote in message
news:co2fmc$28h1$1 digitaldaemon.com...
 It's becoming evident that "every body" will have it's own
 implementation of a String class.

 Walter,
 it's time to add "The String Class" to phobos,
 as simple as it might be. It doesn't have to be a class, actually
 an interface might be a better idea.
 That way all other implementations would extend on the 'official' one
 so there would be a common ground for a String class on every library
 making all libs communicate at least the very common String object
 between each other.

 I could grab all the functions from the phobos string module and package
 them as an interface or package them as an Abstract class
 or a (concret class) - just say the word.

 once Walter said he couldn't imagine a use for extending a String class,
 (neither can Sun as the java String class is final),
 on the next release of dool the Path class will extend the String class.
 Is that a good idea? it's looking good to me for the last 3 days...
 Strings on dool are not imutable.

 Ant

Nov 24 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 24 Nov 2004 21:22:40 +0100, Ivan Senji <ivan.senji public.srce.hr> 
wrote:
 Well, actually i have been very happy with char[] until now.
 How about providing a standard alias like:
 alias char[] string; //or String
 and a bunch of usefull methods like:
 void someOp(string str, int bla)
 {
     //do something with stri and bla
 }
 and then use it in a class-like way:
 string bla;
 bla.someOp(5);

The main concern seems to me to be interfacing between 3rd party libraries, where the library builders may have chosen a different string type char, wchar, or dchar. The same applies to different OS calls which may also require different string types. One solution suggests a string alias: pros: - people will use that alias and thus the same string type cons: - that type is not always ideal in all situations, so some of the time people will use one of the other types and in these cases we have the same problem. One solution suggested is a single string 'class': pros: - everyone will use the same string class. cons: - it's OO for some people the 'con' is not a con, however a standard library should to take into consideration all requirements. One solution suggested was implicit conversion between those types. pros: - it does not matter what string type people choose to use, leaving the freedom to use the 'best' for thier particular library. cons: - conversions cost ideally conversions should only be done at the input and output stages, not all over the place. Another idea I had was to make the string type a compile time option, so the code uses 'string', upon compile 'string' is interpreted as char, wchar or dchar. char, wchar and dchar can still be used where required. Implicit conversions are done. pros: - single type which people will use. - will reduce internal conversions (non input/output conversions) cons: - you will need to build 3rd party libs with the right flag, so they will need to be distributed in 3 forms, one for each char type. Have I missed any? So far none of the above ideas appear the 'best' solution for a standard library. I can understand why OO only types like the String class idea, as for them it has no 'cons'.
 I generally am for the OO design of libs but don't see the need
 for D strings to be OO.

I am of a like mind. Regan
 "Ant" <Ant_member pathlink.com> wrote in message
 news:co2fmc$28h1$1 digitaldaemon.com...
 It's becoming evident that "every body" will have it's own
 implementation of a String class.

 Walter,
 it's time to add "The String Class" to phobos,
 as simple as it might be. It doesn't have to be a class, actually
 an interface might be a better idea.
 That way all other implementations would extend on the 'official' one
 so there would be a common ground for a String class on every library
 making all libs communicate at least the very common String object
 between each other.

 I could grab all the functions from the phobos string module and package
 them as an interface or package them as an Abstract class
 or a (concret class) - just say the word.

 once Walter said he couldn't imagine a use for extending a String class,
 (neither can Sun as the java String class is final),
 on the next release of dool the Path class will extend the String class.
 Is that a good idea? it's looking good to me for the last 3 days...
 Strings on dool are not imutable.

 Ant


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Nov 24 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opshzpf3rn5a2sq9 digitalmars.com...
 On Wed, 24 Nov 2004 21:22:40 +0100, Ivan Senji <ivan.senji public.srce.hr>
 wrote:
 Well, actually i have been very happy with char[] until now.
 How about providing a standard alias like:
 alias char[] string; //or String
 and a bunch of usefull methods like:
 void someOp(string str, int bla)
 {
     //do something with stri and bla
 }
 and then use it in a class-like way:
 string bla;
 bla.someOp(5);

The main concern seems to me to be interfacing between 3rd party libraries, where the library builders may have chosen a different string type char, wchar, or dchar. The same applies to different OS calls which may also require different string types.

Thanks, it looks like i missed what the problem is. Now i think i know.
 One solution suggests a string alias:
 pros:
   - people will use that alias and thus the same string type
 cons:
   - that type is not always ideal in all situations, so some of the time
 people will use one of the other types and in these cases we have the same
 problem.


 One solution suggested is a single string 'class':
 pros:
   - everyone will use the same string class.
 cons:
   - it's OO

 for some people the 'con' is not a con, however a standard library should
 to take into consideration all requirements.


 One solution suggested was implicit conversion between those types.
 pros:
   - it does not matter what string type people choose to use, leaving the
 freedom to use the 'best' for thier particular library.
 cons:
   - conversions cost

 ideally conversions should only be done at the input and output stages,
 not all over the place.


 Another idea I had was to make the string type a compile time option, so
 the code uses 'string', upon compile 'string' is interpreted as char,
 wchar or dchar. char, wchar and dchar can still be used where required.
 Implicit conversions are done.
 pros:
   - single type which people will use.
   - will reduce internal conversions (non input/output conversions)
 cons:
   - you will need to build 3rd party libs with the right flag, so they

 need to be distributed in 3 forms, one for each char type.


 Have I missed any? So far none of the above ideas appear the 'best'
 solution for a standard library. I can understand why OO only types like
 the String class idea, as for them it has no 'cons'.

 I generally am for the OO design of libs but don't see the need
 for D strings to be OO.

I am of a like mind. Regan

Nov 24 2004
prev sibling parent reply unknown <unknown_member pathlink.com> writes:
Is there a built-in String class in D today ?

In article <co2fmc$28h1$1 digitaldaemon.com>, Ant says...
It's becoming evident that "every body" will have it's own
implementation of a String class.

Walter,
it's time to add "The String Class" to phobos,
as simple as it might be. It doesn't have to be a class, actually
an interface might be a better idea.
That way all other implementations would extend on the 'official' one
so there would be a common ground for a String class on every library
making all libs communicate at least the very common String object
between each other.

Ant

Jun 30 2005
next sibling parent Victor Nakoryakov <nail-mail mail.ru> writes:
unknown wrote:
 Is there a built-in String class in D today ?
 

Class... no. Furthermore there is no de facto standart external class like std::string in C++. -- Victor (aka nail) Nakoryakov nail-mail<at>mail<dot>ru Krasnoznamensk, Moscow, Russia
Jul 01 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
unknown wrote:

 Is there a built-in String class in D today ?

No, for some of the reasons outlined in here: http://www.digitalmars.com/d/cppstrings.html In fact, there are even three string _types_... http://prowiki.org/wiki4d/wiki.cgi?CharsAndStrs There are several third-party String variants, like http://mango.dsource.org/classUString.html But it doesn't look like Phobos will ever have one (partly because it's not an object-oriented lib ?) --anders
Jul 01 2005