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

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.

You are right, deprecating those names and removing them in the long run is what I think should be done.

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

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

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

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

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

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

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