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
>> 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?
>
> 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
