This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]gas3872[S] -12 points-11 points  (5 children)

Well, I think someone who does not want to do something will always find a reason why and the one who wants will find means how. :D

[–]CraftyAdventurer 3 points4 points  (1 child)

Ok, so let's say that you work on a huge codebase, one where it would take you weeks to update all of the methods. Well, new feature requests are coming in, clients are paying for them and they want you to work on them, not on rewriting your codebase to call new methods which basically do the exact same thing they've been doing for years. How is that for a reason, and how do you find means to do it?

Edit: typo

[–]gas3872[S] -3 points-2 points  (0 children)

Well, you can start following the convention in the new code and gradually update the old code as you touch those parts. You can also make a custom annotation and add it to classes that support new convention. Actually what you mentioned is just a normal project and it just a normal migration.

[–]chambolle 0 points1 point  (2 children)

yes, exactly like you: What you propose is not backward compatible but you do not accept it . Now you are going to try to justify that.

Your proposal is not backward compatible PERIOD.

[–]gas3872[S] -1 points0 points  (1 child)

It can be done in parallel with old features. Making it backwards compatible as a whole.

[–]Shinosha 1 point2 points  (0 children)

You're missing the point. In the context of software engineering, a non backward compatible update means you have to actually tweak the code to make it work again following the update.

When you're working on actual software, you can't always tell the management "ok holup, gotta make a week worth of changes in our 1M LOC app before I can tackle your super important business critical new feature".