On 09/05/2011 04:51 PM, Walter Bright wrote:
If the new std.path breaks existing code, I need to fix it before it is
released. Please let me know what problems you are experiencing.
It prints out all the deprecation message. It means I'll have to go edit
existing, working code to change the names.
I think it means it gives you time, on your own schedule with generous
deadlines, to make the changes to your code.
I know that the majority wants the name changes. I know the deprecation
system gives people plenty of time to edit their code.
But I think the cost of breaking existing code is much higher than many
realize, and a lot of that cost will be hidden. It'll come in the form
of people deciding not to use D because it is "not stable". It'll come
in the form of invalidating existing libraries and modules unless
someone is regularly maintaining them. It'll come in the form of
invalidating the mass of books, articles, blog postings, and
presentations about D, and those will never get updated. People will
type in the code examples, they will fail to compile, and they'll get
turned off about D.
I'll again note that I know of know successful operating system or
programming language that goes around breaking existing code unless it
is really, really urgent.
Camel-casing a name doesn't meet that standard. So, yes, I don't like it.
I agree with all of the above. However, as is often the case, there's
more than one side to the story.
Bad APIs have their costs too. We can't afford to have an XML library
that offers few and badly packaged features and comes at the tail of all
benchmarks. We also can't afford a JSON library that is poorly designed
and badly written. Ironically, the costs mostly manifest the same way:
people will decide not to use D because it "lacks good libraries" and
"is quirky to use". In many ways a language's standard library is a
showcase of the language, and to a newcomer an inconsistent and awkward
standard library affects the perception of the language's quality.
Stressing that breaking code has a cost and implying that keeping it
with flaws has no cost is as mistaken as worrying in chess about the
flank at the expense of the center.
The reality we need to face is, we are experiencing growth pains. What
we must do is NOT lament about breaking this or keeping that. We must:
a) devise good language features to cope with deprecation, of which
deprecation with message is one that I think we need to embrace and
extend (I have a few ideas I'll discuss separately);
b) supplement that with a good policy for deprecating APIs and
introducing new ones - in particular decide where to draw the line when
introducing a breaking change;
c) possibly create programs a la gofix that help migration.
Andrei
