Speaking of regex.. I see there are two enums in std.regex, email and url, which are regular expressions. Why not collect more of these common regexes? And we could pack them up in a struct to avoid polluting the local namespace. I think this might encourage the use of std.regex, since the average Joe wouldn't have to reach for the regex book whenever he's processing strings. E.g.:

foreach(m; match("10abc20def30", regex(patterns.number))) //
std.regex.patterns.number
{
    writefln("%s[%s]%s", m.pre, m.hit, m.post);
}

Just a passing thought..

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.543.1294713068.4748.digitalmars-d@puremagic.com...
> Speaking of regex.. I see there are two enums in std.regex, email and url, which are regular expressions. Why not collect more of these common regexes? And we could pack them up in a struct to avoid polluting the local namespace. I think this might encourage the use of std.regex, since the average Joe wouldn't have to reach for the regex book whenever he's processing strings. E.g.:
>
> foreach(m; match("10abc20def30", regex(patterns.number))) //
> std.regex.patterns.number
> {
>    writefln("%s[%s]%s", m.pre, m.hit, m.post);
> }
>
> Just a passing thought..

I think that's a great idea.

On 1/9/11 4:51 PM, Andrei Alexandrescu wrote:
> There's a lot of junk in std.string that should be gone. I'm trying to
> motivate myself to port some functions to different string widths and...
> it's not worth it.
>
> What functions do you think we should remove from std.string? Let's make
> a string and then send them the way of the dino.
>
>
> Thanks,
>
> Andrei

I have uploaded a preview of the changed APIs here:

http://d-programming-language.org/cutting-edge/phobos/std_string.html

Let's work together on improving things.


Andrei

Hi Andrei,

It looks nice. Just a small comment: in many of your comments you use words that not all of us might now. For instance: "sans". I happen to know it because I studied French, but otherwise I wouldn't know that. I just showed that phrase to a colleague here in Argentina and he didn't understand it. He thought it maybe meant "since". Maybe "sans" and "in lieu" are memes there in the USA, but not everywhere. So please, stick with English. :-)

Oh, one more thing: can the names be consistent?

inpattern
countChars
expandtabs
chompPrefix
toupper
toupperInPlace ??

If this can't be done for backwards compatibility maybe you can make alias for the previous ones.

Also:

stripl
stripr
strip

Strips *l*eading and *t*railing whitespaces...

It took me some time to notice that it was strip*r* (for right), but the comment says "trailing", and I never think of "remove right space", always "remove trailing spaces" (like in the comment!). So why not name that function "stript"?

On 01/11/2011 04:34 PM, Ary Borenszweig wrote:
> Oh, one more thing: can the names be consistent?
>
> inpattern
> countChars
> expandtabs
> chompPrefix
> toupper
> toupperInPlace ??
>
> If this can't be done for backwards compatibility maybe you can make alias for the
> previous ones.
>
> Also:
>
> stripl
> stripr
> strip
>
> Strips *l*eading and *t*railing whitespaces...

stripLeft, stripRight

Anyway, the necessity for super-cryptic abbreviated names doesn't exist any more. Maybe, they are justified for very frequently used stuff but stripl/stripr is not the case.

>
> It took me some time to notice that it was strip*r* (for right), but the comment
> says "trailing", and I never think of "remove right space", always "remove
> trailing spaces" (like in the comment!). So why not name that function "stript"?

Yes, what I meant was that the names are stripl and stripr yet the description of those functions are strip leading and strip trailing... at least put strip left and string right on the description so it matches the names.

On 01/11/2011 05:36 PM, Ary Borenszweig wrote:
> Yes, what I meant was that the names are stripl and stripr yet the description of
> those functions are strip leading and strip trailing... at least put strip left
> and string right on the description so it matches the names.

Sorry for misunderstanding.

I don't think that the description needs to match the names literally. However, I would aviod "trailing" and "leading", because in RTL environments they can have the opposite meaning.

On 1/11/11 6:29 AM, Ary Borenszweig wrote:
> Hi Andrei,
>
> It looks nice. Just a small comment: in many of your comments you use words that
> not all of us might now. For instance: "sans". I happen to know it because I
> studied French, but otherwise I wouldn't know that. I just showed that phrase to a
> colleague here in Argentina and he didn't understand it. He thought it maybe meant
> "since". Maybe "sans" and "in lieu" are memes there in the USA, but not
> everywhere. So please, stick with English. :-)

Okay. I think "sans" is Walter's...

Andrei

On 1/11/11 6:34 AM, Ary Borenszweig wrote:
> Oh, one more thing: can the names be consistent?
>
> inpattern
> countChars
> expandtabs
> chompPrefix
> toupper
> toupperInPlace ??
>
> If this can't be done for backwards compatibility maybe you can make alias for the
> previous ones.

The names are for compatibility with... other languages :o|.

> Also:
>
> stripl
> stripr
> strip
>
> Strips *l*eading and *t*railing whitespaces...
>
> It took me some time to notice that it was strip*r* (for right), but the comment
> says "trailing", and I never think of "remove right space", always "remove
> trailing spaces" (like in the comment!). So why not name that function "stript"?

Same thing. These names are imported from other languages.


Andrei