breaking changes vs legacy: how gofix solved the problem with automated code transitions

Andrej Mitrovic andrej.mitrovich at gmail.com
Sun May 26 05:59:11 PDT 2013


On 5/26/13, timotheecour <timothee.cour2 at 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. :)


More information about the Digitalmars-d mailing list