On 8 November 2010 10:37, Jörg Schaible <joerg.schai...@gmx.de> wrote: > Hi Sebb, > > sebb wrote: > >> On 8 November 2010 08:49, Jörg Schaible <joerg.schai...@gmx.de> wrote: >>> sebb wrote: >>> >>>> Most of the generics fixes have now been done. >>>> >>>> There are still a few raw Class references; most of these can be fixed >>>> if DefaultFileSystemConfigBuilder.getConfigClass() is changed to >>>> return a FileSystem [1] >>>> >>>> Can anyone else confirm that this is a sensible change? >>>> >>>> [1] https://issues.apache.org/jira/browse/VFS-334 >>> >>> No. We use an implementation of FileSystemConfigBuilder that does also >>> not implement FileSystem to introduce more global configuration >>> parameters. >> >> So? None of the FileSystemConfigBuilder classes currently implement >> FileSystem. >> >>> What you can do is: >>> >>> protected Class<? extends FileSystemConfigBuilder> getConfigClass(); >> >> No, that won't work, because all the other getConfig() methods return >> subclasses of FileSystem. > > I see. > >> The only solution then would be to use Class<?> throughout. >> >> All I'm suggesting is changing the return class from >> DefaultFileSystemConfigBuilder.getConfigClass() to (say) >> FileSystem.class. >> >> The FileSystemConfigBuilder subclass getConfig() methods are not there >> because they implement the FileSystem interface, they implement the >> abstract method in FileSystemComfigBuilder. > > I had a closer look at it now and it seems that Class<?> is the right > solution. Basically the class type is used as a key to the options that > apply for the current file system, but the stuff from > DefaultFileSystemConfiguBuilder are available as options to all FS (as our > implementation of FileSystemConfigBuilder does). It does not necessary have > to be a FileSystem implementation, it's just a natural choice for a FS > implementation.
Would there be any harm in using the FS interface class in this case? i.e., use the implementation class for all real file systems, and use the FileSystem interface for generic options. Won't that work just as well? > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
