|
Re: New refactoring type
|
Posted: Apr 17, 2006 5:40 AM
|
|
> > The paper is more about why C/C++/Java suck rather than > > why mandatory type systems are bad. It actually > presents > > no evidence for 'significant engineering problems'. > > I encounter them. With some refactoring work, I wish I > could just turn off the typing system for a little while, > run the program dynamicaly with tests, and then turn it > back on again. There are times when static typing it gets > in the way. Don't get me started on what it is like to > try to get tests into a statically typed system that > wasn't written with tests in mind. That's a particularly > grievous engineering problem. > > The idea that I want to run with is that typing rules are > really tests and they should be as flexible as tests. I > should be able to, in a particular program, say "I don't > want the Foo class to ever hold a Bar. It can hold > anything else but not a Bar." I know AspectJ can give you > that sort of compile time checking. If the type system is > in the hands of the programmer, it can be another tool to > put additional constraints on a program and alter them on > an as needed basis. > > One could argue that compile time type systems aren't as > strong as they could be because they never become program > specific, they are devised as a tool for all programs in a > specific language.
But the problems you mention are more due to limitations of the programming language you use rather than due to the nature static types work. For example, the problem of 'Foo can hold anything except a Bar' could easily be encoded in a programming language if the type system allowed the programmer to declare types as algebraic sets (and thus the relationship between types can be expressed with set operations).
If you could run the code dynamically, the tests would give you different information. Tests are about behavior among objects. The type system is about how to name and organize sets of those behaviors. Imagine a Java program with no interfaces. You could probably use 'extract interface' a zillion different ways and still have the same behavior.
That is structural subtyping, mentioned here lots of times by Chris Diggins and others.
Because the program may be correct.
What do you mean "may be correct"? a program is either correct or it is not correct. A program that "may be correct" is also a program that "may be erroneous". And in some time in the future, that error may happen. A programming language should make sure such errors are not possible.
Yes, you can do all those kinds of metaprogramming in a statically typed language such as Java too, either doing static metaprogramming via code generation, or at runtime by using reflection, dynamic proxies, dynamic loading of classes that you use via interfaces they implement, etc. But it is a lot easier in a dynamic language. Variables in dynamic languages can just as easily provide access to an object whose class was invented by the running program as a class you wrote by hand in source.
That is not a factor of how dynamic a language is, but how is the language structured. I can make C++ classes at run-time by putting together opcodes and vtables. Does that make C++ dynamic? nope. Does the static type system of C++ prohibit me from doing so? nope.
That's why static typing is having problems. By using dynamic typing, you can have different views of the variables appropriate to the "processing unit" in question.
Again, the problem you mention is not a problem due to static typing, but a problem of implementation: by using interfaces, a dog can see a car as {smell, loudness, color} and a human can see a car as {brand, type, speed}, for example. In dynamic typing system, the interfaces are there, implicit, but there is no way to ensure the coupling at compile time.
|
|