Am 02.04.2015 um 23:55 schrieb Sean P. DeNigris <sean@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