www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - eliminate junk from std.string?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 09 2011
next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--0023547c8d999d2a2804997216d3
Content-Type: text/plain; charset=ISO-8859-1

I think the tr, replace, and translate functions are a bit awkward.

--0023547c8d999d2a2804997216d3
Content-Type: text/html; charset=ISO-8859-1

I think the tr, replace, and translate functions are a bit awkward.

--0023547c8d999d2a2804997216d3--
Jan 09 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
IIRC someone on this NG mentioned that several functions are going
away from std.string and into std.algorithm. This would be nice,
considering I frequently get name clashes when importing both modules
(but at least there's no function hijacking. Thanks, D!).
Jan 09 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 09 January 2011 15:19:31 Jimmy Cao wrote:
 I think the tr, replace, and translate functions are a bit awkward.

Really? I use replace() fairly heavily in string-processing code, and I don't see anything about it which could be considered awkward. tr() is definitely cool. I do think that it is a bit awkward if you want to deal with the modifiers, but my only real gripe is that I can't replace a character with a string of characters (e.g. replace all ":" with " - ") or a string of characters with a single character (e.g. replace all " - " with ":"). But I don't see a good way to do that. Maybe something with regexes would be better. I don't know. But the alternative to tr() in many cases, is multiple calls to replace(), which would cause unnecessary heap allocations. - Jonthaan M Davis
Jan 09 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Sun, 09 Jan 2011 16:51:57 -0600, 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.

My suggestions for things to remove: hexdigits, digits, octdigits, lowercase, letters, uppecase, whitespace - What are these arrays useful for? capwords() - It tries to do too much. zfill() - The ljustify(),rjustify(), and center() functions should instead take an optional padding character that defaults to a space. maketrans(), translate() - I don't even understand what these do. inPattern(), countchars(), removechars() - Pattern matching is std.regex's charter. squeeze(), succ(), tr(), soundex(), column() - I am having a very hard time imagining myself ever using these functions... -Lars
Jan 09 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 My suggestions for things to remove:
 
 hexdigits, digits, octdigits, lowercase, letters, uppecase, whitespace
  - What are these arrays useful for?
 
 capwords()
  - It tries to do too much.
 
 zfill()
  - The ljustify(),rjustify(), and center() functions
    should instead take an optional padding character
    that defaults to a space.
  
 maketrans(), translate()
  - I don't even understand what these do.
 
 inPattern(), countchars(), removechars()
  - Pattern matching is std.regex's charter.
 
 squeeze(), succ(), tr(), soundex(), column()
  - I am having a very hard time imagining myself ever
    using these functions...

I agree with about nothing you have said :-) How much string processing you do day by day? I am using most of those things... If you are used in using Python or Ruby you probably find most of those things useful. If Andrei removes arrays like lowercase, letters, uppecase, I will have to write them myself in code. ljustify(),rjustify(), and center() are very useful, even if they may be improved in some ways. maketrans() and translate() (as other things) come from Python string functions, and I have used them a hundred times in string processing code. I have used squeeze() some times. soundex is not hurting, because even if it's not commonly necessary, its name is easy to understand and it's not easy to miss for something different, so it doesn't add much noise to the library. And I've seen that it's easy to implement soundex wrongly, while the one in the std.string is correct. I agree that too much stuff is generally bad in a library, because searching for something requires more time if there are more items to search into. In Bugzilla I have three or four bug reports that ask for few small changes in std.string (like removing chop and keeping chomp). But please don't remove too much. In a library more is often better. Bye, bearophile
Jan 10 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/11 2:41 AM, bearophile wrote:
 Lars T. Kyllingstad:

 My suggestions for things to remove:

 hexdigits, digits, octdigits, lowercase, letters, uppecase, whitespace
   - What are these arrays useful for?

 capwords()
   - It tries to do too much.

 zfill()
   - The ljustify(),rjustify(), and center() functions
     should instead take an optional padding character
     that defaults to a space.

 maketrans(), translate()
   - I don't even understand what these do.

 inPattern(), countchars(), removechars()
   - Pattern matching is std.regex's charter.

 squeeze(), succ(), tr(), soundex(), column()
   - I am having a very hard time imagining myself ever
     using these functions...

I agree with about nothing you have said :-) How much string processing you do day by day? I am using most of those things... If you are used in using Python or Ruby you probably find most of those things useful. If Andrei removes arrays like lowercase, letters, uppecase, I will have to write them myself in code.

The arrays letters, uppercase, and lowercase aren't all that useful because they only make sense for ASCII. Besides, they should be encoded as functions.
 ljustify(),rjustify(), and center() are very useful, even if
 they may be improved in some ways.

Hmmm. I suspected everyone's list will be different :o). I personally think the justification and centering functions are rarely useful - how often does one need to justify plain text? If you generate HTML the markup will do that for you and if you generate some nice text then the font will be proportional so the functions are useless. Nevertheless, I ported them (and also fixed them - they were broken for anything non-ASCII, which probably is telling of the extent of their usage). What are your use cases for these three functions?
 maketrans() and translate() (as
 other things) come from Python string functions, and I have used them
 a hundred times in string processing code. I have used squeeze() some
 times. soundex is not hurting, because even if it's not commonly
 necessary, its name is easy to understand and it's not easy to miss
 for something different, so it doesn't add much noise to the library.
 And I've seen that it's easy to implement soundex wrongly, while the
 one in the std.string is correct.

I think maketrans/translate are okay (if a bit arcane) but they need to be ported to Unicode. Python apparently does mind Unicode as of 3.x, although I'm not sure exactly what the semantics are: http://stackoverflow.com/questions/3031045/how-come-string-maketrans-does-not work-in-python-3-1. One odd thing is that you'd expect a dynamic language like Python to dynamically detect ASCII vs. non-ASCII. The example shows that Python rejects string-based translation tables even when they are, in fact, ASCII.
 I agree that too much stuff is generally bad in a library, because
 searching for something requires more time if there are more items to
 search into. In Bugzilla I have three or four bug reports that ask
 for few small changes in std.string (like removing chop and keeping
 chomp). But please don't remove too much. In a library more is often
 better.

I think we should remove all functions that rely on patterns represented as strings: inPattern, countchars, removechars, squeeze, munch. Representing patterns as a convention on top of otherwise untyped strings doesn't seem a good solution for D. We should either go with regex or with a simple pattern structure and a helper function. That way people can say e.g. munch(s, pattern("[0-9]")). Andrei
Jan 10 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 What are your use cases for these three functions?

I don't know about bearophile, but I used a lot of the functions you are talking about removing in my HTML -> Plain Text conversion function used for emails and other similar environments. squeeze the whitespace, align text, wrap for the target, etc.
Jan 10 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Adam Ruppe wrote:
 I don't know about bearophile, but I used a lot of the functions
 you are talking about removing in my HTML -> Plain Text conversion
 function used for emails and other similar environments. squeeze the
 whitespace, align text, wrap for the target, etc.

As has been pointed out, a lot of these seemingly odd functions come from Python/Ruby/Javascript. Users of those languages will be familiar with them, and they've proven themselves handy in those languages. Let's not be cavalier about dumping them just because they aren't familiar to C programmers.
Jan 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:igib2q$12g8$3 digitalmars.com...
 Adam Ruppe wrote:
 I don't know about bearophile, but I used a lot of the functions
 you are talking about removing in my HTML -> Plain Text conversion
 function used for emails and other similar environments. squeeze the
 whitespace, align text, wrap for the target, etc.

As has been pointed out, a lot of these seemingly odd functions come from Python/Ruby/Javascript. Users of those languages will be familiar with them, and they've proven themselves handy in those languages. Let's not be cavalier about dumping them just because they aren't familiar to C programmers.

I agree with this reasoning for having them. However, I don't think it means we shouldn't D-ify or Phobos-ify them, at least as far as capitalization conventions.
Jan 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 I agree with this reasoning for having them. However, I don't think it means 
 we shouldn't D-ify or Phobos-ify them, at least as far as capitalization 
 conventions.

I also object to rather pointlessly annoying people wanting to move their code from D1 to D2 by renaming everything. Endlessly renaming things searching for the perfect name gives the illusion of progress, whereas time would be better spent on improving the documentation, unittests, performance, etc. Naming of things isn't nearly as critical an issue in D as it is in, say, C, because of the excellent antihijacking support in D's module system. Some name changes have turned out to be a big win, like "invariant" => "immutable". But I don't think that implies open season for wholesale renaming of swaths of functions.
Jan 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:igifgt$1cuj$1 digitalmars.com...
 Nick Sabalausky wrote:
 I agree with this reasoning for having them. However, I don't think it 
 means we shouldn't D-ify or Phobos-ify them, at least as far as 
 capitalization conventions.

I also object to rather pointlessly annoying people wanting to move their code from D1 to D2 by renaming everything. Endlessly renaming things searching for the perfect name gives the illusion of progress, whereas time would be better spent on improving the documentation, unittests, performance, etc. Naming of things isn't nearly as critical an issue in D as it is in, say, C, because of the excellent antihijacking support in D's module system. Some name changes have turned out to be a big win, like "invariant" => "immutable". But I don't think that implies open season for wholesale renaming of swaths of functions.

We're not asking for free-for-all bikeshedding, we're asking to get rid of the free-for-all naming-convention-carnival in the std lib. Just basic sensible consistency, that's all. And breaking compatibility with D1 for the sake of progress is the whole point of D2.
Jan 11 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Lars T. Kyllingstad wrote:
 1. What are the hexdigits, digits, octdigits, lowercase, letters, 
 uppercase, and whitespace arrays useful for?  The only thing I can think 
 of is to check whether a character belongs to one of them,

One example is conversion from a number to text. hexdigits[n] comes to mind. If you do a strings dump on a random executable, you'll usually find such strings embedded in it. By putting them in std.string, hopefully you won't find several instances of the same string.
Jan 11 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 10 Jan 2011 03:41:51 -0500, bearophile wrote:

 Lars T. Kyllingstad:
 
 My suggestions for things to remove:
 
 hexdigits, digits, octdigits, lowercase, letters, uppecase, whitespace
  - What are these arrays useful for?
 
 capwords()
  - It tries to do too much.
 
 zfill()
  - The ljustify(),rjustify(), and center() functions
    should instead take an optional padding character that defaults to a
    space.
  
 maketrans(), translate()
  - I don't even understand what these do.
 
 inPattern(), countchars(), removechars()
  - Pattern matching is std.regex's charter.
 
 squeeze(), succ(), tr(), soundex(), column()
  - I am having a very hard time imagining myself ever
    using these functions...

I agree with about nothing you have said :-) How much string processing you do day by day? I am using most of those things... If you are used in using Python or Ruby you probably find most of those things useful. If Andrei removes arrays like lowercase, letters, uppecase, I will have to write them myself in code. ljustify(),rjustify(), and center() are very useful, even if they may be improved in some ways. maketrans() and translate() (as other things) come from Python string functions, and I have used them a hundred times in string processing code. I have used squeeze() some times. soundex is not hurting, because even if it's not commonly necessary, its name is easy to understand and it's not easy to miss for something different, so it doesn't add much noise to the library. And I've seen that it's easy to implement soundex wrongly, while the one in the std.string is correct.

I think you may have misunderstood some of my suggestions. For instance, I never proposed to remove ljustify(), rjustify(), and center(). Rather, I would have them take an extra 'padding' parameter, so we can eliminate zfill(). Before: auto s = zfill("123", 6); After: auto s = rjustify("123", 6, '0'); As for the other things I suggested, well... those are the things i vote to remove from std.string. If they only get that one vote, they stay. ;) By the way, since you seem to be using these things quite often, maybe you can answer this: 1. What are the hexdigits, digits, octdigits, lowercase, letters, uppercase, and whitespace arrays useful for? The only thing I can think of is to check whether a character belongs to one of them, but I think that is better done with the std.ctype functions. 2. What do maketrans() and translate() do? (A brief example would be nice.) -Lars
Jan 10 2011
parent "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:igeia5$1t4a$4 digitalmars.com...
 1. What are the hexdigits, digits, octdigits, lowercase, letters,
 uppercase, and whitespace arrays useful for?  The only thing I can think
 of is to check whether a character belongs to one of them, but I think
 that is better done with the std.ctype functions.

They're good for people like me who never noticed std.ctype ;)
Jan 10 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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..
Jan 10 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Jan 10 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 "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.

I agree.
Jan 11 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 10 2011
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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. :-)
Jan 11 2011
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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"?
Jan 11 2011
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
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"?

Jan 11 2011
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Jan 11 2011
parent reply Max Samukha <spambox d-coding.com> writes:
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.
Jan 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Max Samukha" <spambox d-coding.com> wrote in message 
news:ighvca$api$1 digitalmars.com...
 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.

I would have thought RTL languages got stored as RTL. If so, then "leading" and "trailing" would be correct and "left"/"right" would be wrong (unless the internal behavior of stripl and stripr takes language-direction into account, which would surprise me).
Jan 11 2011
parent Max Samukha <spambox d-coding.com> writes:
On 01/11/2011 08:18 PM, Nick Sabalausky wrote:
 "Max Samukha"<spambox d-coding.com>  wrote in message
 news:ighvca$api$1 digitalmars.com...
 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.

I would have thought RTL languages got stored as RTL. If so, then "leading" and "trailing" would be correct and "left"/"right" would be wrong (unless the internal behavior of stripl and stripr takes language-direction into account, which would surprise me).

AFAIK, there is no universal standard on storing RTL text. There are recommendations to prefer logical order over visual order because visual order is extremely inflexible. I am not an expert in this field and have to shut up.
Jan 11 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:igi18o$e5e$2 digitalmars.com...
 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|.

Would that other language be Walterish or C? If C, it's not like using the wrong case will suddendly change the semantics of the function. And if the worry is other non-phobos functions that might have the old C-style name (but different semantics), then Ary's suggestion of compatibly-named alases would take care of that.
Jan 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:igi18o$e5e$2 digitalmars.com...
 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.


Would that other language be Walterish or C?

The names generally come from Python, Ruby and Javascript.
Jan 11 2011
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Why care where they come from? Why not make them intuitive? Say, like, "Always
camel case"?
Jan 11 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, "Always
 camel case"?

Because people are used to those names due to their wide use. It's the same reason that we still use Qwerty keyboards.
Jan 11 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.01.2011 20:42, schrieb Walter Bright:
 Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, "Always
 camel case"?

Because people are used to those names due to their wide use. It's the same reason that we still use Qwerty keyboards.

And C++ :-P
Jan 11 2011
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Agreed. So what's wrong with improving things and leaving old things as aliases?
Jan 11 2011
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
"Welcome to D. Do you program in C, Javascript, Python or Ruby? Cool! Then you
will feel at home."

That phrase currently ends like this:

"You don't? Oh, sorry, you will have to learn that some names are all lowercase,
some not."

But it could end like this:

"You don't? Don't worry. D has the convention of writing all function names
with X
convention, but we keep some aliases for things that we want to keep backwards
compatibility for."
Jan 11 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.01.2011 21:11, schrieb Ary Borenszweig:
 "Welcome to D. Do you program in C, Javascript, Python or Ruby? Cool! Then you
 will feel at home."

 That phrase currently ends like this:

 "You don't? Oh, sorry, you will have to learn that some names are all
lowercase,
 some not."

I agree. Using different conventions for naming functions etc makes a library look inconsistent. Yeah right, those names are used in other languages, so people who know C, Javascript, Python and Ruby may feel at home (even though there may be similar functions with different names/writing and signatures in e.g. JS and Ruby so one still has to know, where exactly the function was "stolen"). I can to some degree understand to reuse C function names/signatures, with D being a successor and compatible and all, but reusing names (and especially their writing - lowercase, lowercase_with_underscores, CamelCase, ...) from a plethora of languages/libraries doesn't make Phobos look and feel consistent but stitched together like Frankensteins Monster. It's definitely good to adapt functions that have proven useful in other languages/libraries. But they should be adjusted to fit within the style of the own library, especially when it's a standard library. There is a D style guide ( http://www.digitalmars.com/d/2.0/dstyle.html ), so at least D's own standard library should comply with it :-) Cheers, - Daniel
Jan 11 2011
prev sibling parent Don <nospam nospam.com> writes:
spir wrote:
 On 01/11/2011 09:11 PM, Ary Borenszweig wrote:
 "Welcome to D. Do you program in C, Javascript, Python or Ruby? Cool! 
 Then you
 will feel at home."

 That phrase currently ends like this:

 "You don't? Oh, sorry, you will have to learn that some names are all 
 lowercase,
 some not."

 But it could end like this:

 "You don't? Don't worry. D has the convention of writing all function 
 names with X
 convention, but we keep some aliases for things that we want to keep 
 backwards
 compatibility for."

Yop. And anyway those legacy names are not all the same in C, Javascript, Python, Ruby, etc.. One has to be chosen or created for D, why not follow a guideline for the standard D name? (I really cannot (under)stand this general politic of sticking at wrong design choices from the past for generations and generations --even in brand new languages. How do improvements happen in other fields than programming? One day or the other, one needs to throw away old (mental) garbage.) Denis

Yes, I recently did the same with many of the math functions. tgamma --> gamma, lgamma -> logGamma. It's pretty funny to try to find out why there is a 't' in front of 'tgamma' in C. http://pubs.opengroup.org/onlinepubs/009695399/functions/tgamma.html "RATIONALE This function is named tgamma() in order to avoid conflicts with the historical gamma() and lgamma() functions." And why the t? 't' stands for 'true'. Because the original gamma() had a bug. Bravo.
Jan 12 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Ary Borenszweig wrote:
 Agreed. So what's wrong with improving things and leaving old things as
aliases?

Clutter. One of the risks with Phobos development is it becoming a river miles wide, and only an inch deep. In other words, endless gobs of shallow, trite functions, with very little depth. (Aliases are as shallow as they get!) As a general rule, I don't want functionality in Phobos that takes more time for a user to find/read/understand the documentation on than to reimplement it himself. Those things give the illusion of comprehensiveness, but are just useless wankery. Do we really want a 1000 page reference manual on Phobos, but no database interface? No network interface? No D lexer? No disassembler? No superfast XML parser? No best-of-breed regex implementation? No CGI support? No HTML parsing? No sound support? No jpg reading? I worry by endless bikeshedding about perfecting the spelling of some name, we miss the whole show. I'd like to see more meat. For example, Don has recently added gamma functions to the math library. These are hard to implement correctly, and are perfect for inclusion.
Jan 11 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Ary Borenszweig wrote:
 Agreed. So what's wrong with improving things and leaving old things as
aliases?

I want to add that having multiple names for the same thing doesn't really do anyone any good.
Jan 11 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/11/11 12:09 PM, Ary Borenszweig wrote:
 Agreed. So what's wrong with improving things and leaving old things as
aliases?

Petrified lava. Andrei
Jan 11 2011
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
So what's a good use for aliases?
Jan 11 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.01.2011 00:59, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 15:29:54 Ary Borenszweig wrote:
 So what's a good use for aliases?

2. Deprecating a function name. For instance, let's say that we rename splitl to splitL or SplitLeft in std.string. Having a deprecated alias to splitl would avoid immediately breaking code.

Isn't this exactly what Ary had in mind? :-)
Jan 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.01.2011 01:17, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 16:07:11 Daniel Gibson wrote:
 Am 12.01.2011 00:59, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 15:29:54 Ary Borenszweig wrote:
 So what's a good use for aliases?

2. Deprecating a function name. For instance, let's say that we rename splitl to splitL or SplitLeft in std.string. Having a deprecated alias to splitl would avoid immediately breaking code.

Isn't this exactly what Ary had in mind? :-)

No, or at least that's not the impression that I got. I understood that he meant to have to aliases around permanently. It's just confusing and adds clutter to do things like have both splitl and splitLeft (or splitL or whotever splitl got renamed to) around in the long run. _That_ is what Andrei and Walter is objecting to. Renaming a function and having a deprecated alias to the old name for a few releases eases the transition would definitely be good practice. aliasing a function just to have another name for the same thing wouldn't be good practice. There has to be a real benefit to having the second name. Providing a smooth deprecation route would be a case where there's a real benefit. - Jonathan M Davis

Ok, you're right, that is a slight difference. Deprecating them is certainly a good idea, but I'd suggest to keep the deprecated aliases around for longer (until D3), so anybody porting a Phobos1-based application to D2/Phobos2 can use them, even if he doesn't do this within the next few releases. Cheers, - Daniel
Jan 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.01.2011 01:55, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 16:23:13 Daniel Gibson wrote:
 Deprecating them is certainly a good idea, but I'd suggest to keep the
 deprecated aliases around for longer (until D3), so anybody porting a
 Phobos1-based application to D2/Phobos2 can use them, even if he doesn't
 do this within the next few releases.

Well, leaving an alias until D3 would equate to a permanent alias in D2, which is exactly what Walter and Andrei don't want (and I don't either). There's already plenty in Phobos 2 that's different from Phobos 1. So, while I don't think that we should rename stuff just to rename stuff, I also don't think that we should keep aliases around just to make porting D1 code easier - especially when most D1 code is probably using Tango anyway. We don't really have a policy in place for how long deprecation should last prior to outright removal, but until D3 is definitely too long. I would have thought that the question would be more along the lines of whether it should be a couple of releases or more like 6 months to a year before removing deprecated functions and modules at this point, not whether something will remain deprecated until D3. - Jonathan M Davis

Somewhere in this thread: Am 11.01.2011 21:43, schrieb Walter Bright:
 Nick Sabalausky wrote:
 I agree with this reasoning for having them. However, I don't think it
 means we shouldn't D-ify or Phobos-ify them, at least as far as
 capitalization conventions.

I also object to rather pointlessly annoying people wanting to move their code from D1 to D2 by renaming everything. Endlessly renaming things searching for the perfect name gives the illusion of progress, whereas time would be better spent on improving the documentation, unittests, performance, etc.

So his objection was specifically that renaming those functions could annoy people migrating D1 code (and certainly he meant Phobos1 users, because Tango-people either port (parts of) Tango or will have to rewrite that anyway). So, to accomplish that goal (not annoying those people), these aliases should be kept for longer. (An alternative may be to one/some phobos1-compat modules that contain such aliases and maybe even wrappers with old signatures for new functions, that could be imported to ease porting of old applications. That would have the benefit of not cluttering the regular Phobos2 modules with that legacy stuff.) Cheers, - Daniel
Jan 11 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.01.2011 03:10, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 17:17:43 Daniel Gibson wrote:
 Am 12.01.2011 01:55, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 16:23:13 Daniel Gibson wrote:
 Deprecating them is certainly a good idea, but I'd suggest to keep the
 deprecated aliases around for longer (until D3), so anybody porting a
 Phobos1-based application to D2/Phobos2 can use them, even if he doesn't
 do this within the next few releases.

Well, leaving an alias until D3 would equate to a permanent alias in D2, which is exactly what Walter and Andrei don't want (and I don't either). There's already plenty in Phobos 2 that's different from Phobos 1. So, while I don't think that we should rename stuff just to rename stuff, I also don't think that we should keep aliases around just to make porting D1 code easier - especially when most D1 code is probably using Tango anyway. We don't really have a policy in place for how long deprecation should last prior to outright removal, but until D3 is definitely too long. I would have thought that the question would be more along the lines of whether it should be a couple of releases or more like 6 months to a year before removing deprecated functions and modules at this point, not whether something will remain deprecated until D3. - Jonathan M Davis

Somewhere in this thread: Am 11.01.2011 21:43, schrieb Walter Bright: > Nick Sabalausky wrote: >> I agree with this reasoning for having them. However, I don't think it >> means we shouldn't D-ify or Phobos-ify them, at least as far as >> capitalization conventions. > > I also object to rather pointlessly annoying people wanting to move > their code from D1 to D2 by renaming everything. Endlessly renaming > things searching for the perfect name gives the illusion of progress, > whereas time would be better spent on improving the documentation, > unittests, performance, etc. So his objection was specifically that renaming those functions could annoy people migrating D1 code (and certainly he meant Phobos1 users, because Tango-people either port (parts of) Tango or will have to rewrite that anyway). So, to accomplish that goal (not annoying those people), these aliases should be kept for longer. (An alternative may be to one/some phobos1-compat modules that contain such aliases and maybe even wrappers with old signatures for new functions, that could be imported to ease porting of old applications. That would have the benefit of not cluttering the regular Phobos2 modules with that legacy stuff.)

Well, I didn't say that Walter wasn't concerned about it. I just don't see the point. Phobos has changed enough from D1 to D2 that even D1 Phobos users (of which I get the impression there are relatively few) that there's probably already plenty of stuff which is going to break for anyone porting over. I do think that keeping a deprecated alias around longer for a function which has been around longer makes sense, and the Phobos 1 functions have been around longer than anything else. So, deprecating a function that was added 2 releases ago probably shouldn't require a deprecated alias for as long as deprecating a function that was in Phobos 1 would, but there's still a limit to how long it makes sense. And given that your average D1 user uses Tango rather than Phobos, it makes that much less sense to keep aliases to Phobos 1 functions around for a long time. So, no, we shoudln't get rid of the deprecated alias for a Phobos 1 function after only a release or two, but I don't think that it makes sense to keep it around for a year or two either. - Jonathan M Davis

Hmm maybe. I guess there will be further similar discussions (e.g. the depreation of std.stream once the successor is ready). I think those aliases should at least be kept until all Phobos1 stuff that is to be replaced is indeed replaced. That'd allow a decision that is at least consistent for most Phobos1 stuff (some has already been removed/replaced, e.g. by the druntime modules like core.thread). Cheers, - Daniel
Jan 11 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/12/2011 02:17 AM, Daniel Gibson wrote:
 Somewhere in this thread:

 Am 11.01.2011 21:43, schrieb Walter Bright:
  > Nick Sabalausky wrote:
  >> I agree with this reasoning for having them. However, I don't think it
  >> means we shouldn't D-ify or Phobos-ify them, at least as far as
  >> capitalization conventions.
  >
  > I also object to rather pointlessly annoying people wanting to move
  > their code from D1 to D2 by renaming everything. Endlessly renaming
  > things searching for the perfect name gives the illusion of progress,
  > whereas time would be better spent on improving the documentation,
  > unittests, performance, etc.
  >

 So his objection was specifically that renaming those functions could
 annoy people migrating D1 code (and certainly he meant Phobos1 users,
 because Tango-people either port (parts of) Tango or will have to
 rewrite that anyway).
 So, to accomplish that goal (not annoying those people), these aliases
 should be kept for longer.

 (An alternative may be to one/some phobos1-compat modules that contain
 such aliases and maybe even wrappers with old signatures for new
 functions, that could be imported to ease porting of old applications.
 That would have the benefit of not cluttering the regular Phobos2
 modules with that legacy stuff.)

When D2 / Phobos2 stabilise, what about a semi-automatic porting tool (at least signaling potential issues, first of all occurrences of deprecated stdlib names)? Denis _________________ vita es estrany spir.wikidot.com
Jan 11 2011
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
You are right, deprecating those names and removing them in the long
run is what I think should be done.
Jan 11 2011
prev sibling parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
On 01/11/2011 07:17 PM, Jonathan M Davis wrote:
 Renaming a function and having a deprecated alias to the old name for a few 
 releases eases the transition would definitely be good practice. aliasing a 
 function just to have another name for the same thing wouldn't be good
practice. 
 There has to be a real benefit to having the second name. Providing a smooth 
 deprecation route would be a case where there's a real benefit.

How about wrapping the aliases up in, e.g., std.compatibility.{c, javascript, python, …} Well, maybe not in std; that might imply a commitment to keep up-to-date full library compatibility forever. But it might make a semi-useful contrib library. --Joel
Jan 23 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 11, 2011 15:29:54 Ary Borenszweig wrote:
 So what's a good use for aliases?

Oh, there's not necessarily anything wrong with aliases. The problem is if an API has a lot of them. The typical place to use typedef in C++ is when you have long, nasty template types which you don't want to actually have to type out, and while auto and D's improved templates reduce the need for that sort of typedef, I'm sure that folks will still want to use them for that sort of thing. Personally, I've used them for three things: 1. When there's a templated function that you want to be able to call with a set of specific names. A prime example would be get on core.time.Duration. It properly genericizes dealing that functionality, but it would be annoying to have to type duration.get!"days"(), duration.get!"hours", etc. all over the place, so it aliases them to the properties days, hours, etc. 2. Deprecating a function name. For instance, let's say that we rename splitl to splitL or SplitLeft in std.string. Having a deprecated alias to splitl would avoid immediately breaking code. 3. In the new std.datetime, DateTimeException is an alias of core.time.TimeException, so that you can use the same exception type throughout the time stuff (std.datetime also publicly imports core.time) without worrying whether it was core.time or std.datetime which threw the exception and yet still have an exception type with the same name as the module as is typical in a number of Phobos modules. So, you get one exception type for all of the time code but still follow the typical naming convention. However, none of these are things that I'd do very often. alias is a tool that can be very handy at times, and I think that it's very good that we have, it but using it all over the place is likely ill-advised - especially if all you're really doing with it is making it possible to call the same function with different names. I'd say that, on the whole, aliases should be used when they simplify code or when renaming functions or types, and you want a good deprecation path, but other than that, in general, it's probably not a good idea to use them much. - Jonathan M Davis
Jan 11 2011
prev sibling next sibling parent Max Samukha <spambox d-coding.com> writes:
On 01/11/2011 09:42 PM, Walter Bright wrote:
 Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

Because people are used to those names due to their wide use. It's the same reason that we still use Qwerty keyboards.

We should be careful in assuming what people are used to. Compare: D/Python/Lisp/... - strip .NET/Delphi/Java/Qt/Haskell/... - Trim/trim/trimmed stripl/stripr are TrimStart/TrimEnd in .NET
Jan 11 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:igibu6$154q$1 digitalmars.com...
 Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, 
 "Always
 camel case"?

Because people are used to those names due to their wide use. It's the same reason that we still use Qwerty keyboards.

Then why switch langauges at all? When you move to a different language you expect that language is going to have its own set of conventions. And even more than that, you also expect it to at least be internally-consistent, not a grab-bag of different styles. Are they really supposed to remember "Oh, oh, this func comes from this language, so it's capitalized this way, and that one comes from that language so it's capitalized that way..." Not only that, but D has far, far bigger, more significant differences from Ruby/Python/JS/etc than the capitalization of a few functions. If people are going to come over and get used to *those* changes, then using toLower instead of tolower is going to be a downright triviality for them. Your cart is before your horse.
Jan 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 11, 2011 12:44:57 Nick Sabalausky wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:igibu6$154q$1 digitalmars.com...
 
 Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

Because people are used to those names due to their wide use. It's the same reason that we still use Qwerty keyboards.

Then why switch langauges at all? When you move to a different language you expect that language is going to have its own set of conventions. And even more than that, you also expect it to at least be internally-consistent, not a grab-bag of different styles. Are they really supposed to remember "Oh, oh, this func comes from this language, so it's capitalized this way, and that one comes from that language so it's capitalized that way..." Not only that, but D has far, far bigger, more significant differences from Ruby/Python/JS/etc than the capitalization of a few functions. If people are going to come over and get used to *those* changes, then using toLower instead of tolower is going to be a downright triviality for them. Your cart is before your horse.

I agree. Having the functions named similarly so that they're quickly recognized is good - if a function has a particular name in a variety of languages, why not give it essentially the same name in D? But I don't see why it must be _exactly_ the same name. At least using the same casing as the rest of Phobos. Unless you're directly porting code, the fact that it's toLower instead of tolower really shouldn't be an issue. It's a new a language, a new library, you're going to have to learn how it works anyway. The function names don't need to be _exactly_ the same as other languages. It does look bad when functions in Phobos don't follow the same naming conventions as the rest of it, and it makes it much harder to remember exactly how they're named. So, I'm all for picking names which are essentially the same as functions with the same functionality in other languages, but I think that insisting that the casing of the names match the casing of the functions from other languages when it doesn't match how functions are normally cased in Phobos is definitely a bad idea. Not to mention, I don't think that I've ever heard anyone complain that the casing on a function in Phobos didn't match the casing of a function with essentially the same name in another language, but complaints definitely pop up about how some of the std.string functions don't use the same casing as the rest of Phobos. I vote for consistency. Using essentially the same names for functions as is used in other languages is great. Insisting on the same casing for the function names strikes me as inconsistent and undesirable. I find that it increases the burden of remembering function names rather than reducing it. - Jonathan M Davis
Jan 11 2011
prev sibling parent Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 1/11/2011 2:42 PM, Walter Bright wrote:
 Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

Because people are used to those names due to their wide use. It's the same reason that we still use Qwerty keyboards.

I disagree strongly with this. I remember function names phonetically in my head. I don't want to have to remember which language it came from in order to know what the casing should be. And these function names aren't nearly standardized as a qwerty keyboard. And besides, D makes much more radical departures from languages in other areas (which is usually a good thing). Php is already ridiculed for its library having no internal consistency. I don't want the same thing to happen to phobos.
Jan 13 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei
Jan 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.01.2011 00:00, schrieb Andrei Alexandrescu:
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei

Please do, having different naming conventions of functions within the standard library makes it harder to remember the exact spelling of a function and also doesn't look professional. +1 vote for making the standard library comply with the D style guide[1] Cheers, - Daniel [1] http://digitalmars.com/d/2.0/dstyle.html
Jan 11 2011
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-11 20:28:27 -0500, spir <denis.spir gmail.com> said:

 But while we're at conventions, and before any change is actually done, 
 we may take the opportunity to agree not only on morphology, but on 
 semantics ;-)
 
 For instance, from online doc:
 string capitalize(string s);
      Capitalize first character of string s[], convert rest of string 
 s[] to lower case.
 Then, use it:
      auto s = "capital";
      s.capitalize();
      writeln(s);         // "capital"
 Uh?
 Not only the name is misleading, but the doc as well.
 
 For this kind of issue, some guidelines read like:
 * perform an action --> action verb (eg capitalise: changes the passed string)
 * return a result --> named after result (eg capitalised: return new string)
 Sure, the func's interface also tells the reader what's actually done. 
 But having name (and doc) contradict it is not very helpful. And beeing 
 forced to open the doc or even the source for every unknown bit is an 
 annoying obstacle.
 
 There are probably other common issues like this. My personal 
 evaluation is whether some newcomer can guess the purpose of the func, 
 the type, the constant, etc...
 
 I would also vote for:
 * full words, except for rare exception used everywhere in programming 
 _and_ really helpful (eg OS)
 * get rid of obscure, ambiguous, or misleading namings
 * when possible, use international words rather than english-only (eg 
 section better than slice if everything else equal)

I support this too. Names should be easy to read. That said, I'm not exactly sure about what you mean by this "use international words" recommendation. I really don't get why "section" would be better than "slice". Words that exists in other languages don't always have the exact same meaning as in English, so they might also be more confusing to an international audience. I'd stick with the "choose a meaningful word" rule. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 11 2011
prev sibling next sibling parent David Nadlinger <see klickverbot.at> writes:
On 1/12/11 12:00 AM, Andrei Alexandrescu wrote:
 If there's enough support for this, I'll do it.

 Andrei

+1 from me – sticking to names commonly used in other programming languages is good for ease of adoption, but also inheriting the various naming convention is, in my humble opinion, just plain weird. David
Jan 11 2011
prev sibling next sibling parent BlazingWhitester <max.klyga gmail.com> writes:
On 2011-01-12 01:00:51 +0200, Andrei Alexandrescu said:

 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei

++vote. Uniformity in how functions are named will improve readibility.
Jan 11 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-11 18:00:51 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, "Always
 camel case"?

If there's enough support for this, I'll do it.

I support this. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 11 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:iginid$1rtg$2 digitalmars.com...
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, 
 "Always
 camel case"?

If there's enough support for this, I'll do it.

I've already been arguing in favor of it :) vote++;
Jan 11 2011
prev sibling next sibling parent Justin Johansson <noreply jj.com> writes:
On 12/01/11 10:00, Andrei Alexandrescu wrote:
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

If there's enough support for this, I'll do it.

Yes please; it's got my vote.
Jan 11 2011
prev sibling next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:

 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always camel case"?

If there's enough support for this, I'll do it. Andrei

+1
Jan 12 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-12 00:00, Andrei Alexandrescu wrote:
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei

vote++ -- /Jacob Carlborg
Jan 12 2011
prev sibling next sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like, 
 "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei

++vote. Bear in mind that with D's spell checker, the error message is: test.d(8): Error: undefined identifier tolower, did you mean function toLower? Which is pretty darn good.
Jan 12 2011
prev sibling next sibling parent Paolo Invernizzi <arathorn fastwebnet.it> writes:
Andrei Alexandrescu Wrote:
 
 If there's enough support for this, I'll do it.
 
 Andrei

for how much it can be worth, +1 Paolo
Jan 12 2011
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 12.01.2011 2:00, Andrei Alexandrescu wrote:
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say,
 like, "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei

-- Dmitry Olshansky
Jan 12 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/01/2011 23:00, Andrei Alexandrescu wrote:
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei

+1 vote. -- Bruno Medeiros - Software Engineer
Jan 28 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vo5kspmfeav7ka steve-laptop...
 On Tue, 11 Jan 2011 11:39:11 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

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

sans is in the english dictionary: http://www.merriam-webster.com/dictionary/sans According to that reference, Shakespeare used it :) Don't think you can get more English than that...

Thoust words are true. Seriously though, I'm pretty sure a lot of native english speakers don't know "sans" either, unless they're familiar with font-related terminology. "In lieu of" is widely-known though, at least in the US.
Jan 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.01.2011 19:07, schrieb Nick Sabalausky:
 Thoust words are true.

 Seriously though, I'm pretty sure a lot of native english speakers don't
 know "sans" either, unless they're familiar with font-related terminology.
 "In lieu of" is widely-known though, at least in the US.

I'm neither representative nor a native speaker (I'm german) and I knew sans, but didn't know "In lieu of".
Jan 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:igi6n5$27pv$1 digitalmars.com...
 Am 11.01.2011 19:07, schrieb Nick Sabalausky:
 Thoust words are true.

 Seriously though, I'm pretty sure a lot of native english speakers don't
 know "sans" either, unless they're familiar with font-related 
 terminology.
 "In lieu of" is widely-known though, at least in the US.

I'm neither representative nor a native speaker (I'm german) and I knew sans, but didn't know "In lieu of".

I guess that just goes to show, we should all just switch to Esperanto ;)
Jan 11 2011
prev sibling next sibling parent Justin Johansson <noreply jj.com> writes:
On 12/01/11 05:07, Nick Sabalausky wrote:
 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vo5kspmfeav7ka steve-laptop...
 On Tue, 11 Jan 2011 11:39:11 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:

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

sans is in the english dictionary: http://www.merriam-webster.com/dictionary/sans According to that reference, Shakespeare used it :) Don't think you can get more English than that...

Thoust words are true.

As an aside you might find some amusement in "The Shakespeare Programming Language" http://shakespearelang.sourceforge.net/report/shakespeare/
Jan 11 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 Seriously though, I'm pretty sure a lot of native english speakers don't 
 know "sans" either, unless they're familiar with font-related terminology. 
 "In lieu of" is widely-known though, at least in the US.

I used to keep a dictionary on my desk, but now I just google definitions. I don't see a good reason to dumb down the language. BTW, english is full of french words, thanks to the Battle of Hastings.
Jan 11 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Jan 2011 11:39:11 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

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

sans is in the english dictionary: http://www.merriam-webster.com/dictionary/sans According to that reference, Shakespeare used it :) Don't think you can get more English than that... BTW, it would be impossible to phrase everything so everyone who has their specific dialect of English would understand it, I don't think there's much sense in worrying about it. That being said, using 'without' instead of 'sans' is probably fine. -Steve
Jan 11 2011
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 11 Jan 2011 15:00:51 -0800, Andrei Alexandrescu wrote:

 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always camel case"?

If there's enough support for this, I'll do it. Andrei

++vote IMO, this should be done throughout Phobos before it's too late. -Lars
Jan 12 2011
prev sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Wed, 12 Jan 2011 08:00:51 +0900, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,  
 "Always
 camel case"?

If there's enough support for this, I'll do it.

++vote :) Masahiro
Jan 12 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/11/2011 04:11 PM, Max Samukha wrote:
 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.

+++ Standard names should all be as obvious as possible. Then, everyone is free to alias stripLeft & stripRight to sl & sr ;-) But standard lib should be super clear code; show the right example of what clarity means --not the opposite! And I ask again: what to do with all inherited junk breaking naming rules like uint, size_t, malloc...? Denis _________________ vita es estrany spir.wikidot.com
Jan 11 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 01/11/2011 07:14 PM, Nick Sabalausky wrote:
 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:igi6n5$27pv$1 digitalmars.com...
 Am 11.01.2011 19:07, schrieb Nick Sabalausky:
 Thoust words are true.

 Seriously though, I'm pretty sure a lot of native english speakers don't
 know "sans" either, unless they're familiar with font-related
 terminology.
 "In lieu of" is widely-known though, at least in the US.

I'm neither representative nor a native speaker (I'm german) and I knew sans, but didn't know "In lieu of".

I guess that just goes to show, we should all just switch to Esperanto ;)

No, esperanto is just a heap of language-design errors! Denis _________________ vita es estrany spir.wikidot.com
Jan 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.550.1294771968.4748.digitalmars-d puremagic.com...
 On 01/11/2011 07:14 PM, Nick Sabalausky wrote:
 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:igi6n5$27pv$1 digitalmars.com...
 Am 11.01.2011 19:07, schrieb Nick Sabalausky:
 Thoust words are true.

 Seriously though, I'm pretty sure a lot of native english speakers 
 don't
 know "sans" either, unless they're familiar with font-related
 terminology.
 "In lieu of" is widely-known though, at least in the US.

I'm neither representative nor a native speaker (I'm german) and I knew sans, but didn't know "In lieu of".

I guess that just goes to show, we should all just switch to Esperanto ;)

No, esperanto is just a heap of language-design errors!

And that differs from English, how? ;)
Jan 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/11/2011 07:01 PM, Nick Sabalausky wrote:
 The names are for compatibility with... other languages :o|.


If C, it's not like using the wrong case will suddendly change the semantics of the function. And if the worry is other non-phobos functions that might have the old C-style name (but different semantics), then Ary's suggestion of compatibly-named alases would take care of that.

Agreed, Ary's suggestion makes much sense. Anyway, when shall we endly get rid of half-a-century-old naming issues? In the XXIInd century? Denis _________________ vita es estrany spir.wikidot.com
Jan 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 11, 2011 11:12:44 Nick Sabalausky wrote:
 "spir" <denis.spir gmail.com> wrote in message
 news:mailman.550.1294771968.4748.digitalmars-d puremagic.com...
 
 On 01/11/2011 07:14 PM, Nick Sabalausky wrote:
 "Daniel Gibson"<metalcaedes gmail.com>  wrote in message
 news:igi6n5$27pv$1 digitalmars.com...
 
 Am 11.01.2011 19:07, schrieb Nick Sabalausky:
 Thoust words are true.
 
 Seriously though, I'm pretty sure a lot of native english speakers
 don't
 know "sans" either, unless they're familiar with font-related
 terminology.
 "In lieu of" is widely-known though, at least in the US.

I'm neither representative nor a native speaker (I'm german) and I knew sans, but didn't know "In lieu of".

I guess that just goes to show, we should all just switch to Esperanto ;)

No, esperanto is just a heap of language-design errors!

And that differs from English, how? ;)

English wasn't designed. - Jonathan M Davis
Jan 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 11, 2011 16:07:11 Daniel Gibson wrote:
 Am 12.01.2011 00:59, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 15:29:54 Ary Borenszweig wrote:
 So what's a good use for aliases?

2. Deprecating a function name. For instance, let's say that we rename splitl to splitL or SplitLeft in std.string. Having a deprecated alias to splitl would avoid immediately breaking code.

Isn't this exactly what Ary had in mind? :-)

No, or at least that's not the impression that I got. I understood that he meant to have to aliases around permanently. It's just confusing and adds clutter to do things like have both splitl and splitLeft (or splitL or whotever splitl got renamed to) around in the long run. _That_ is what Andrei and Walter is objecting to. Renaming a function and having a deprecated alias to the old name for a few releases eases the transition would definitely be good practice. aliasing a function just to have another name for the same thing wouldn't be good practice. There has to be a real benefit to having the second name. Providing a smooth deprecation route would be a case where there's a real benefit. - Jonathan M Davis
Jan 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/11/2011 09:11 PM, Ary Borenszweig wrote:
 "Welcome to D. Do you program in C, Javascript, Python or Ruby? Cool! Then you
 will feel at home."

 That phrase currently ends like this:

 "You don't? Oh, sorry, you will have to learn that some names are all
lowercase,
 some not."

 But it could end like this:

 "You don't? Don't worry. D has the convention of writing all function names
with X
 convention, but we keep some aliases for things that we want to keep backwards
 compatibility for."

Yop. And anyway those legacy names are not all the same in C, Javascript, Python, Ruby, etc.. One has to be chosen or created for D, why not follow a guideline for the standard D name? (I really cannot (under)stand this general politic of sticking at wrong design choices from the past for generations and generations --even in brand new languages. How do improvements happen in other fields than programming? One day or the other, one needs to throw away old (mental) garbage.) Denis _________________ vita es estrany spir.wikidot.com
Jan 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 11, 2011 16:23:13 Daniel Gibson wrote:
 Am 12.01.2011 01:17, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 16:07:11 Daniel Gibson wrote:
 Am 12.01.2011 00:59, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 15:29:54 Ary Borenszweig wrote:
 So what's a good use for aliases?

2. Deprecating a function name. For instance, let's say that we rename splitl to splitL or SplitLeft in std.string. Having a deprecated alias to splitl would avoid immediately breaking code.

Isn't this exactly what Ary had in mind? :-)

No, or at least that's not the impression that I got. I understood that he meant to have to aliases around permanently. It's just confusing and adds clutter to do things like have both splitl and splitLeft (or splitL or whotever splitl got renamed to) around in the long run. _That_ is what Andrei and Walter is objecting to. Renaming a function and having a deprecated alias to the old name for a few releases eases the transition would definitely be good practice. aliasing a function just to have another name for the same thing wouldn't be good practice. There has to be a real benefit to having the second name. Providing a smooth deprecation route would be a case where there's a real benefit. - Jonathan M Davis

Ok, you're right, that is a slight difference. Deprecating them is certainly a good idea, but I'd suggest to keep the deprecated aliases around for longer (until D3), so anybody porting a Phobos1-based application to D2/Phobos2 can use them, even if he doesn't do this within the next few releases.

Well, leaving an alias until D3 would equate to a permanent alias in D2, which is exactly what Walter and Andrei don't want (and I don't either). There's already plenty in Phobos 2 that's different from Phobos 1. So, while I don't think that we should rename stuff just to rename stuff, I also don't think that we should keep aliases around just to make porting D1 code easier - especially when most D1 code is probably using Tango anyway. We don't really have a policy in place for how long deprecation should last prior to outright removal, but until D3 is definitely too long. I would have thought that the question would be more along the lines of whether it should be a couple of releases or more like 6 months to a year before removing deprecated functions and modules at this point, not whether something will remain deprecated until D3. - Jonathan M Davis
Jan 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/12/2011 12:07 AM, Daniel Gibson wrote:
 Am 12.01.2011 00:00, schrieb Andrei Alexandrescu:
 On 1/11/11 11:21 AM, Ary Borenszweig wrote:
 Why care where they come from? Why not make them intuitive? Say, like,
 "Always
 camel case"?

If there's enough support for this, I'll do it. Andrei

Please do, having different naming conventions of functions within the standard library makes it harder to remember the exact spelling of a function and also doesn't look professional. +1 vote for making the standard library comply with the D style guide[1]

+1 as well But while we're at conventions, and before any change is actually done, we may take the opportunity to agree not only on morphology, but on semantics ;-) For instance, from online doc: string capitalize(string s); Capitalize first character of string s[], convert rest of string s[] to lower case. Then, use it: auto s = "capital"; s.capitalize(); writeln(s); // "capital" Uh? Not only the name is misleading, but the doc as well. For this kind of issue, some guidelines read like: * perform an action --> action verb (eg capitalise: changes the passed string) * return a result --> named after result (eg capitalised: return new string) Sure, the func's interface also tells the reader what's actually done. But having name (and doc) contradict it is not very helpful. And beeing forced to open the doc or even the source for every unknown bit is an annoying obstacle. There are probably other common issues like this. My personal evaluation is whether some newcomer can guess the purpose of the func, the type, the constant, etc... I would also vote for: * full words, except for rare exception used everywhere in programming _and_ really helpful (eg OS) * get rid of obscure, ambiguous, or misleading namings * when possible, use international words rather than english-only (eg section better than slice if everything else equal) Finally, take the opportunity to make the doc usable, eg: string format(...); Format arguments into a string. ??? Denis _________________ vita es estrany spir.wikidot.com
Jan 11 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 11, 2011 17:17:43 Daniel Gibson wrote:
 Am 12.01.2011 01:55, schrieb Jonathan M Davis:
 On Tuesday, January 11, 2011 16:23:13 Daniel Gibson wrote:
 Deprecating them is certainly a good idea, but I'd suggest to keep the
 deprecated aliases around for longer (until D3), so anybody porting a
 Phobos1-based application to D2/Phobos2 can use them, even if he doesn't
 do this within the next few releases.

Well, leaving an alias until D3 would equate to a permanent alias in D2, which is exactly what Walter and Andrei don't want (and I don't either). There's already plenty in Phobos 2 that's different from Phobos 1. So, while I don't think that we should rename stuff just to rename stuff, I also don't think that we should keep aliases around just to make porting D1 code easier - especially when most D1 code is probably using Tango anyway. We don't really have a policy in place for how long deprecation should last prior to outright removal, but until D3 is definitely too long. I would have thought that the question would be more along the lines of whether it should be a couple of releases or more like 6 months to a year before removing deprecated functions and modules at this point, not whether something will remain deprecated until D3. - Jonathan M Davis

Somewhere in this thread: Am 11.01.2011 21:43, schrieb Walter Bright: > Nick Sabalausky wrote: >> I agree with this reasoning for having them. However, I don't think it >> means we shouldn't D-ify or Phobos-ify them, at least as far as >> capitalization conventions. > > I also object to rather pointlessly annoying people wanting to move > their code from D1 to D2 by renaming everything. Endlessly renaming > things searching for the perfect name gives the illusion of progress, > whereas time would be better spent on improving the documentation, > unittests, performance, etc. So his objection was specifically that renaming those functions could annoy people migrating D1 code (and certainly he meant Phobos1 users, because Tango-people either port (parts of) Tango or will have to rewrite that anyway). So, to accomplish that goal (not annoying those people), these aliases should be kept for longer. (An alternative may be to one/some phobos1-compat modules that contain such aliases and maybe even wrappers with old signatures for new functions, that could be imported to ease porting of old applications. That would have the benefit of not cluttering the regular Phobos2 modules with that legacy stuff.)

Well, I didn't say that Walter wasn't concerned about it. I just don't see the point. Phobos has changed enough from D1 to D2 that even D1 Phobos users (of which I get the impression there are relatively few) that there's probably already plenty of stuff which is going to break for anyone porting over. I do think that keeping a deprecated alias around longer for a function which has been around longer makes sense, and the Phobos 1 functions have been around longer than anything else. So, deprecating a function that was added 2 releases ago probably shouldn't require a deprecated alias for as long as deprecating a function that was in Phobos 1 would, but there's still a limit to how long it makes sense. And given that your average D1 user uses Tango rather than Phobos, it makes that much less sense to keep aliases to Phobos 1 functions around for a long time. So, no, we shoudln't get rid of the deprecated alias for a Phobos 1 function after only a release or two, but I don't think that it makes sense to keep it around for a year or two either. - Jonathan M Davis
Jan 11 2011