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

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

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

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

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

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

So what's a good use for aliases?

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

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? :-)

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