Summary
Why don't we treat it like a set of tests?

I've had a lot of feedback since my last blog. A few people pointed out that Common Lisp and Erlang do something similar. Several people pointed toward Guido's desire to add static typing to Python (I had read about that.. it would be cool to see if this separate compiled type annotation thing could work in Python), and several pointed toward Gilad Bracha's paper on pluggable type systems [PDF] and it looks like the same idea. I knew someone had to have thought of this before. I wish I'd seen those references earlier :-(

One thing I'm wondering, though. In that paper, Gilad talks about type systems being pluggable. What would it be like if they were end user extendable? I know AspectJ allows you to produce errors and warnings based upon static aspects that you specify. For instance, you can have AspectJ produce an error if a someone creates an object of a particular class using new in another particular class. Essentially, that extends the type system.. but from another point of view, couldn't it be seen as a test for a design constraint?

Let's try this point of view on for a second.. The type system of a language is really a set of tests, run by the compiler or the generated runtime. Perhaps we should treat the static end of a type system as a set of tests. Make it them programmable. A project could start out with a set of constraints, as tests, and elaborate them as the project progresses.

Talk Back!

Have an opinion? Readers have already posted 73 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.