There's been someinterestingdiscussion in the Ruby community about "lazy" or "latent" typing - the key idea being that rather than putting type annotations for variables into the code, you extract the information from a running program. You can then use this information for web service introspection, or autocompletion in an IDE, etc. I think this is an excellent answer to statements I commonly hear like "dynamic language environments can never have real Intellisense" - just cause the type information isn't written into the source code doesn't mean it's not accessible. And it's a lot easier to implement for us simple object folk than ML or Haskell style Hindley-Milner type inference.
This approach seems a natural fit for Smalltalk, because image-based development means you've always got running code and live instances easily available for inspection by the IDE. Unlike the Ruby solutions that require doing a special run of your program to collect the information, a Smalltalk environment could just incrementally collect type information in the background as you run test cases and so on (JITted VMs already do this, in fact, but for optimization purposes). Then, say, when you hover your mouse over a variable name, it can pop up a tooltip with its best guess as to type, if it has one (the one time it definitely wouldn't know anything yet is when you're writing a new method, but that's also when you least need the information).
The only thing like this I know about for Squeak is the very cool Instance based Class Diagram tool. This will automatically build a UML-like diagram of the relationships between a set of classes based on examining any instances it can find. But instance variable types aren't enough - to really convince a manifest typing nut, we'd want parameter types and temporary variable types too. There are a couple of ways I would approach this. The first would be to have a background process that worked much like the statistical profiler that comes with Squeak: every once in a while it would wake up and scan the stack of the active process. Instead of recording the call graph, however, it would record type information. The problem with this is that it would miss short or infrequently called methods. So I'd also want to do something like wrapping a method whenever it's compiled, recording type info the first time (or first N times) the method is invoked, and then unwrapping it so it runs at full speed thereafter.
So I'm curious to hear from those in the OO manifest typing camp that are scared about the readability of dynamic languages - would this address your concerns at all? Or do you only feel secure when a human programmer has specified each and every type in the system by hand? (I know the functional language people won't like it, but that's a whole different standard of type safety).
Previous Topic
