commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject RE: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java
Date Wed, 19 Aug 2009 06:07:50 GMT

Hi!

> > IF you use the options in a way which allows you to know which kind
> > of filesystem will be used - good - but then the builder is just
> > another layer, but not awkward and brittle I think.
> 
> No. They are awkward and brittle. WebDavFileSystemConfigBuilder
> extends HttpFileSystemConfigBuilder. The getInstance method has to
> return an HttpFileSystemConfigBuilder since you can't change the
> return value of an overridden method.

Probably it is time to upgrade the minor jdk version for VFS-2.0.
Starting with JDK 1.5 you can change the return type of an overridden method. It is called,
covariant return types.
http://www.java-tips.org/java-se-tips/java.lang/covariant-return-types.html

Probably long overdue and an easy fix then.


> > FileSystemOption then can be a concrete instance of a set of
> > configurations for one specific filesystem, so you might have
> > HttpFileSystemOption, SftpFileSystemOption etc. Each of them holding
> > all possible filesystem options.
> 
> I actually like this a lot more than the current implementation.
> However, it wouldn't allow the get and set methods to be exposed at
> compile time on the root FileSystemOptions class. I think that can be
> worked around pretty easily.

Yes, if we consistently name the new subclasses, we can instantiate these and reflect the
getter/setter then.


Ciao,
Mario

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


Mime
View raw message