Breaking backwards compatiblity

[deadalnix]

Le 11/03/2012 21:16, Walter Bright a écrit :
> On 3/11/2012 8:34 AM, deadalnix wrote:
>> I do think better name isn't the problem. The problem is about
>> consistency, and
>> will persist as long as we don't agree on a guideline on that in phobos.
>>
>> Changing a name just for changing it doesn't worth the cost, unless
>> the original
>> name is horribly misleading - rare case. But getting the naming
>> convention
>> consistent is of much greater importance, and justify breaking code.
>
> Frankly, I think naming conventions are overrated. The problem is that,
> as the sec vs seconds debate shows, there is not a correct answer. It
> becomes a bikeshed issue. There are a lot of considerations for a name,
> usually conflicting with each other. To set rules in concrete and follow
> them no matter what is a formula for silly results.
>

I think this example is very good. The seconds/secs show us the 
importance of getting consistent. Here the problem come from the fact 
that some stuff has been abbreviated (msecs, usecs, . . .) and some 
other hasn't (minutes, hours). Now we ends up with the tricky case of 
seconds, because it is in between theses 2 worlds and 2 naming 
conventions. And as we have seen, it confuses people, and have no good 
solution now (either duplication of the value, which is never good, 
either arbitrary choice of one naming convention).

This typically show us what problems bad naming convention occurs, and 
how difficult it is solve afterward, because it breaks compatibility.

> I'm not suggesting no naming convention. Naming conventions are good.
> But they don't trump everything else in importance, not even close.
>

I have to disagree. They are really important on a large codebase (let 
say > 100,000 lines of code). Otherwise people tend not to find modules 
they can reuse expect by nowing the whole codebase. This have indirect 
effect to cause needless duplication - with all known drawbacks - and 
make the project more dependent on documentation - more documentation 
have to be produced, which means an overhead in workload and more 
trouble when documentation lacks, is outdated, or is bugguy.

> And sometimes, a name change can be a huge win - the
> invariant=>immutable one is an example. But I think that's an
> exceptional case, not a rule.

IMO, the name in itself isn't that important. The important thing is 
that thing get named in a predictable and simple way.