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

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

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

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

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

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

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

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

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

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)