Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

small improvements for tango.text.String

Moderators: kris

Posted: 06/04/07 16:28:24 Modified: 06/04/07 16:29:53

- allow concatenation of multiple Strings, like: result = Str("a") ~ Str("b") ~ Str("c");

- static opCall based creation for String like used in the previous line (The line was from one of my programs, where I did: "alias String!(char) Str;")

- slicing in ranges: "mystring[]" returns the full content, like "mystring.select.selection", but in a way that is faster to execute and shorter to write so why not allow: mystring[0 .. 5] return the same content like mystring.select(0, 5).selection

my tango rev: 2209, String.d was last changed: 2174 you find the patched file at:

http://mitglied.lycos.de/Daniel919/String.d

Please take a look at it and apply the changes.

Best regards,

Daniel

Author Message

Posted: 06/04/07 19:28:44

Daniel919 wrote:

Using static opCall() for creation/assignment (unfortunately) does not always work. I posted about this some time ago, and Walter said he'd perhaps look into a simpler syntax for new/assign at some point. I'm not aware that he's done that yet?

Isn't there a mystring.slice() that returns the valid content? We'd rather avoid indexing if possible, since the String class tries hard to sidestep that model due to issues around unicode indexing. But perhaps we should add indexing as an option? Method select(x, y) was intended only as a last resort. What is it that you're doing which requires indexing as the primary api?

- Kris

Posted: 06/05/07 11:39:04

Using static opCall() for creation/assignment (unfortunately) does not always work

That's a pity, because

result = (new Str("a")) ~ (new Str("b")) ~ (new Str("c"));

looks ugly.

the String class tries hard to sidestep that model due to issues around unicode indexing

mystring[0 .. 5] can be seen as an shorter version for mystring.select(0, 5).selection.

It does not necessarily mean you have to return exactly: content[0 .. 5]. Special unicode treatment can be done anyway.

What's the problem about unicode indexing ?

mystring.select(0, 5).selection

final String select (int start=0, int length=int.max)
{
pinIndices (start, length);
selectPoint = start;
selectLength = length;
return this;
}

final T[] selection ()
{
return slice [selectPoint .. selectPoint+selectLength];
}

mystring[0 .. 5]

final T[] slice (int start, int end)
{
return content [start .. end];
}

They return the same content, where is the difference for unicode handling ?

What is it that you're doing which requires indexing as the primary api?

I was just trying out the String class. Because mystring[] returns the full content, I initially expected mystring[0 .. 5] should work, too. If this short version is definitely not wished, then I would suggest to also remove mystring[] and instead force the use of mystring.select.selection;

Posted: 06/09/07 22:44:32

huh .. myString[] should not be there :)

But you do bring up a good point. If ppl really need indexed access, then we should probably support it properly