breaking changes: how gofix solved the problem of automated code transitions

[Timothee Cour]

There is a dilemma of having to choose between:
A) getting stuck with bad names / apis / language issues forever
B) making painful breaking changes that breaks existing code

See recent D threads for all the polemics this creates on (in)stability of
D.

GO avoids this dilemma with the correct approach, IMO: automation of code
transition.
See this article for details on gofix:
http://blog.golang.org/2011/04/introducing-gofix.html

gofix operates on the AST of the code and performs AST manipulations (no
fragile 'sed' / regex based bash scripts!), followed by printing them back
to the source code. This is made possible by gofmt, which formats source
code.

Here's a snippet from the article:

"Gofix has already made itself indispensable. In particular, the recent
reflect changes would have been unpalatable without automated conversion,
and the reflect API badly needed to be redone. Gofix gives us the ability
to fix mistakes or completely rethink package APIs without worrying about
the cost of converting existing code."

This is what we need for D if we want to avoid getting stuck in this
dilemma.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130525/fb0445ce/attachment.html>