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

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

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

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.

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

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/

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

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

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

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