|
Re: Programming with "Duh" Typing
|
Posted: Jul 9, 2007 9:31 AM
|
|
> This is a good concrete example and I'd like to continue > with it. > > Now, when you say you can change the address to be an > Object in the dynamic language without changing the rest > of the code, I assume you are making this new object so > that it acts like a string object. If this is not what > you mean please humor me and clarify a bit.
Maybe the address example isn't the best one to use to answer your question, but I'll see if I can continue with it.
So, let's say there's a "Person" class that has an "address" field, which is currently a string. There are a bunch of methods that treat it as a string, calling length(), substring(), matchRegex(), and other such string methods on it. Now, I want to change address to be an object with separate "street", "city", "state", and "zip" fields. This new object type doesn't support the string methods, nor do I want it to. (I don't want address to go on through life pretending to be a string.)
Anyway, I'm concerned that the new Person constructor will properly parse an address string into its component fields. (Yeah, I know, the Address constructor should do the parsing, but humor me.) I write a few unit tests that exercise the Person constructor's parsing routines, in order to test whether parsing is even feasible.
There are two possible changes I can make. The straightforward change is just to change the type of the address field to be an object for the sake of running these tests. The problem is, now I have to go through and change all of the methods that assume the address is a string. The other change is to add another field, parsedAddress, for the sake of running the tests. The problem is that if the tests turn out to be feasible, I have to rename "parsedAddress" to "address" and then update the parsing routines to use the new name.
Again, this is a rather contrived example, where the choice is obvious. But there are situations where it's a real PITA to change the type of an object only to discover that there's a scenario where the new type doesn't work and you have to change it all again. Granted, this can happen in both dynamic and static languages, but it seems to be much more common [for me] in the static ones.
|
|