Sven Van Caekenberghe-2 wrote > Having subclasses for each scheme is hard to maintain (there are hundreds > of schemes)... It also makes little sense implementation wise.
I’m not understanding. For one thing, in Core, we’re not interested in all of the hundreds of schemes but just the few most common (http, file) - although users interested in the specifics of other schemes could easily add those subclasses in their apps. Since subclassing is just a way to share code, wouldn’t a ZnFileUrl merely consist of exactly the methods we’re talking about - but more simply implemented? For one thing, it seems it would make extension easier. If I wanted to handle FileUrls and HttpUrls polymorphically with separate classes, no problem - implement two methods. But as it is now, IIUC I have to either implement two operation classes or have a method with a budding switch statement. Also, IMHO implementing a custom multiple dispatch seems exotic enough (i.e. takes extra effort to understand) to require a large benefit to justify. My 2c ----- Cheers, Sean -- View this message in context: http://forum.world.st/FileUrl-Removal-Rationale-tp4816536p4817064.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
