commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [VFS] Generics fixes
Date Tue, 09 Nov 2010 17:10:08 GMT
Hi Sebb,

sebb wrote:

> On 9 November 2010 09:28, Jörg Schaible <joerg.schaible@gmx.de> wrote:
>> sebb wrote:
>>
>>> On 8 November 2010 10:37, Jörg Schaible <joerg.schaible@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.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message