Re: [VFS] Generics fixes
sebb wrote: 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? Works with: protected Class? extends FileSystem getConfigClass(); - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Generics fixes
On 9 November 2010 09:28, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
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?
Works with:
protected Class? extends FileSystem getConfigClass();
Yes, this works for all but DefaultFileSystemConfigBuilder (which why
I raised the JIRA).
I get the error:
Type mismatch: cannot convert from
ClassDefaultFileSystemConfigBuilder to Class? extends FileSystem
What is wrong with coding DefaultFileSystemConfigBuilder as follows:
protected Class? extends FileSystem getConfigClass()
{
return FileSystem.class; // previously
DefaultFileSystemConfigBuilder.class
}
would this not 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
Re: [VFS] Generics fixes
On 9 November 2010 17:10, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Sebb,
sebb wrote:
On 9 November 2010 09:28, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 8 November 2010 10:37, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Sebb,
sebb wrote:
[snip]
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?
Works with:
protected Class? extends FileSystem getConfigClass();
Yes, this works for all but DefaultFileSystemConfigBuilder (which why
I raised the JIRA).
I get the error:
Type mismatch: cannot convert from
ClassDefaultFileSystemConfigBuilder to Class? extends FileSystem
What is wrong with coding DefaultFileSystemConfigBuilder as follows:
protected Class? extends FileSystem getConfigClass()
{
return FileSystem.class; // previously
DefaultFileSystemConfigBuilder.class
}
would this not work just as well?
Basically, yes, but how do you ensure, that no other (custom) FS
implementation is using FileSystem.class? Either create a private dummy or
you have to document it that the interface as type is used for this key.
Probably safer to use a dummy class.
Also this is closer to what the code does currently (i.e. provides its
own class name).
- 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
Re: [VFS] Generics fixes
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. What you can do is: protected Class? extends FileSystemConfigBuilder getConfigClass(); - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Generics fixes
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. 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. - 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
Re: [VFS] Generics fixes
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. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Generics fixes
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
