On 21/10/2013 20:50, Pisarev, Vitaliy wrote:
I appreciate the quick response.
I looked at the code of PassThroughFileSystem, and I must say it underlines my
point here. In case someone wants to interpose on the default provider, he has
to write all this boiler plate code.
And unless they are aware of the PassThroughFileSystem, they will probably not
do it right. The point being that the mechanism is not friendly for extension
by developers.
Since delegation is the only feasible method available, I wonder whether you
have any plans for introducing facilities that will allow extension by
inheritance, or put some other hooks in place?
The reason I am insisting is because I think that a file system abstraction is
a very powerful concept and I would definitely like to know whether you are
planning to invest in this in the future.
Replacing or interposing on the default file system provider is really
something for more advanced libraries, I don't think it's something that
the vast majority of developers will likely do. So this is why there
isn't a DelegatingFileSystemProvider or some such support in the API. If
there is further effort put into this area then a higher priority (in my
view) would be the base classes to use when developing your own file
system provider. The feedback from those that developed their own file
system providers (for custom file systems usually) is that it's a lot of
effort, particular to the get Path operations right.
-Alan.
