> Am 02.04.2015 um 23:55 schrieb Sean P. DeNigris <s...@clipperadams.com>: > > 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. > I think the problem is that URI structure/format and interpretation are mixed together generating that problem. Sven is right about not having additional classes for URIs. An URI is an URI regardless how it looks like
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / \ urn:example:animal:ferret:nose The authority is optional, so URI wise there is no difference between a file URI and another one. The difference is in the interpretation of them. The interpreting part (the handler) is selected by the scheme. Having scheme as a registry would enable one to register his own handler for dealing with certain schemes. The downside is that dealing with URIs would be harder because you would need to use an extra selector between all calls that does the dispatch over the handler. A anZnUrl handler asFileReference This way there would be a FileHandler that implements #asFileReference. Other handlers might give a DNU. I understand the wish to keep the usage of ZnUrl simple not having to use extra selectors. But that wish turns out to be the problem IMHO and subclassing ZnUrl is not a cure for it just a way to make it worse. my 2 cents, Norbert
