www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - breaking changes vs legacy: how gofix solved the problem with

reply "timotheecour" <timothee.cour2 gmail.com> writes:
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.
May 25 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 26.05.2013 08:32, schrieb timotheecour:
 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.

Before that, we need to have the compiler available as library, that is what Go guys kind of do. -- Paulo
May 26 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/26/13, timotheecour <timothee.cour2 gmail.com> wrote:
 This is what we need for D if we want to avoid getting stuck in
 this dilemma.

It's good for fixing 99% of the cases. But don't forget we also have string mixins (and string imports), which can't easily be fixed. Because of that we shouldn't allow ourselves to be *too* open towards breaking code just because there would be a conversion tool available. Also, if you have a list of dependencies and all of that code ends up breaking, you may end up having to wait for maintainers to update their code. For various reasons you may end up waiting for too long (e.g. maybe the only developer with commit rights to a dependency goes to a vacation). So this becomes another complication. What I'm saying is, a conversion tool doesn't solve all problems. I'd rather we focus on not breaking code. The use of aliases and deprecation stages is nicer, it allows your codebase to be compilable with several versions of the compiler. With automatic code conversion you'd end up having to maintain several branches of your library just to make it compilable with different D releases. As for *language* changes, we are likely getting closer to the point where there won't be any large breaking changes anymore. Anyway, the tool isn't a bad idea at all, let's just not make it an excuse to break too much code too many times. :)
May 26 2013