Log in

fusiongyro wrote
on December 3rd, 2008 at 07:12 pm

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?

(Read Comments)

No HTML allowed in subject


Notice! This user has turned on the option that logs your IP address when posting. 

(will be screened)