I tried it last night. I'm working on a system which uses URNs. I wanted a clean abstraction, both so other URN applications could be built on this, and also so I don't wind up asking myself if I've dealt with the URN specification while working underneath it.
It occurred to me that the namespacing system of the URN is a great candidate for having some kind of dispatch function. So when you parse a URN, you get back a generiic URN if there's no handler for that namespace, but if there is, you get a special subclass back.
Initially I was just going to have it create and return a new instance of the subclass after creating the superclass, but then I found your blog entry and thought I'd try it out with CHANGE-CLASS. So far, I think it's quite nice. I could even write some magical stuff that would just try and locate the class by the namespace identifier and issue the change class, and I wouldn't even have to have a dispatch table of identifier -> functions.
It seems appropriate to me in this case (and in your case) to use CHANGE-CLASS because we're converting between similar things (actually just casting down the inheritance hierarchy.) Based on what little I know, I could definitely make a case for CHANGE-CLASS being bad if one were going to change between unrelated classes a lot, but for these border situations it doesn't seem like a bad architecture to me at all.
Has your opinion of it changed at all in the last year?