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


perhaps

 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


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





 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