I've begun publishing DeprecationTools. It is my belief that while Deprecation is a fun little framework to have, that it's the tools that will make or break use of it. You can now rename a method and check the "Leave Deprecate" check box. Which rather than removing the method, leaves it in place with a call to the new (including any argument permuting). What's cool, is that I believe if the UI hooks were there to enable it, you get for free because of this, not only the rename method, but remove and add parameter refactorings. And even inline parameter (which I've never actually used).

I think I'll do a "deprecate" menu option for methods next and then move on to variable bindings. And then query tools. For example, "I'd like to see all of the deprecated references (method or variable binding) in this package (sigh, or bundle)."

One thing that's come up, discussing here at OOPSLA, is the notion of deferred refactoring of future call sites. Adrian actually commented as to such in the last blog post. I hadn't read it til about 15 minutes ago. Ironically, Roger Whitney had discussed this earlier today. When I mentioned it to Don Roberts, he noted he'd thought of this as well.

So right now, when you deprecate something with the Deprecation package, you get an actual first class object. A "Deprecated" object. And it can "takeAction." The idea here was that I could enable different independent actions to be taken on a global basis. Such as Transcript logging. Or exceptiion raising. It would be a cinche to add a 3rd option now called "rewrite call site." As well, augment the DeprecationEncountered exception to have a defaultAction branch which allowed you to rewrite the call site.

It turns out that the guys at GemStone have done a little deprecation thing too. So I'm getting excited about the possibility for this.