Another reason why I like static typing
I just finished porting a fledgling project of mine from one version of a library API to a new one. The decision to convert was a no-brainer since the designers of the library had improved the API quite a bit over the previous one, and of course I wanted to be able to follow future updates.
But the authors hadn't actually bothered to describe the changes or anything, so I just basically dropped the new JAR over the old one and looked at the red error markers scattered over the code files that turned up in Eclipse. This is the key place where static typing made life much easier: I had a clear map of what needed to be updated and how much work it looked like it was going to be.
Things ranging from the obvious, like missing classes due to renaming, to more abstract errors such as unimplemented interface methods and exceptions that were no longer thrown were flagged. What was left was actual semantic changes and, after grokking some of their updated example code, a few search and replaces later: done.
All in all, surprisingly painless considering I was going in blind. With a dynamically-typed app it I suspect it would have been considerably less scientific. I suppose I'd start by running tests and build a list of missing method errors (assuming I have 100% test coverage).
But even when fixing these and having the tests pass I'd still be paranoid: what about "accidental" passes? Things like changed parameter lists, where extra parameters passed in but no longer used. And what happens when you use a library that uses dynamic tricks like handling missing methods in some clever way so what you're calling is no longer necessarily doing what you think it is?
Don't get me wrong, I think things like this are very cool and would probably use them myself. But I worry that there is a price, which is to make the code harder to understand and evolve.
But the authors hadn't actually bothered to describe the changes or anything, so I just basically dropped the new JAR over the old one and looked at the red error markers scattered over the code files that turned up in Eclipse. This is the key place where static typing made life much easier: I had a clear map of what needed to be updated and how much work it looked like it was going to be.
Things ranging from the obvious, like missing classes due to renaming, to more abstract errors such as unimplemented interface methods and exceptions that were no longer thrown were flagged. What was left was actual semantic changes and, after grokking some of their updated example code, a few search and replaces later: done.
All in all, surprisingly painless considering I was going in blind. With a dynamically-typed app it I suspect it would have been considerably less scientific. I suppose I'd start by running tests and build a list of missing method errors (assuming I have 100% test coverage).
But even when fixing these and having the tests pass I'd still be paranoid: what about "accidental" passes? Things like changed parameter lists, where extra parameters passed in but no longer used. And what happens when you use a library that uses dynamic tricks like handling missing methods in some clever way so what you're calling is no longer necessarily doing what you think it is?
Don't get me wrong, I think things like this are very cool and would probably use them myself. But I worry that there is a price, which is to make the code harder to understand and evolve.
posted by Matthew Phillips at
8:16 pm
|
0 comments
