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
Class<DefaultFileSystemConfigBuilder> 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
