January 12, 2011
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
++vote

-- 
Dmitry Olshansky

January 12, 2011
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.
January 14, 2011
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.
January 23, 2011
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
January 28, 2011
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
1 2 3 4 5 6 7 8 9
Next ›   Last »