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

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.

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.

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

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.

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.

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.

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

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

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