[vfs] Interfaces Re: [vfs][REVOTE] release version 1.0

[Stephen Colebourne <sc...@btopenworld.com>]

Another query, are you happy that you will never want to add a method to 
FileObject, or any other interface in VFS?

Commons tends to be strict about not allowing changes like this. 
Possible solutions to adding a method in the future are
- to create a FileObject2 subinterface
- to go to version 2.0

Alternatively define FileObject (and possibly other interfaces) as an 
abstract class now, then you don't have the same problems.

At the very least, if you think that you might change the interface, you 
should add in the javadoc that it might change in v2.0.

Stephen


Mario Ivankovits wrote:
> Hi!
> 
> Even if the last vode passed I decided to restart the voting based on RC7.
> RC7 is now using commons-net 1.4.1 and built using the jdk1.3 compiler 
> also some rearrangements have taken place to accommodate to our 
> guidlines (e.g. include xdocs into src distribution)
> 
> As previously posted please find the RC7 at 
> http://people.apache.org/~imario/vfs
> 
> Please vote:
> 
> [ ] +1  I support this release and am willing to help
> [ ] +0  I support this release but am unable to help
> [ ] -0  I do not support this release
> [ ] -1  I do not support this release, and here are my reasons
> 
> 
> Sorry if this revote bothers you, but after all what happens in the last 
> days on our mailinglist I thought if would be better to do so.
> 
> Thanks!
> Mario
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 

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

Re: [vfs] Interfaces Re: [vfs][REVOTE] release version 1.0

[Mario Ivankovits <ma...@ops.co.at>]

Hi Stephen!
> Another query, are you happy that you will never want to add a method 
> to FileObject, or any other interface in VFS?
No.

> Alternatively define FileObject (and possibly other interfaces) as an 
> abstract class now, then you don't have the same problems.
There is already a AbstractFileObject (the same for other interfaces 
too). Every developer is hold to extend from AbstractFileObject instead 
of FileObject as it provides some environmental work for you.
But when it comes to decoration I'll be happy with the FileObject 
interfaces alone. E.g. I plan to get the caching stuff out of 
AbstractFileObject and put it into an CachingFileObjectDecorator - then 
I cant use the AbstractfileObject but would like to use the FileObject 
interface - maybe - this decision hasnt been made now.

> At the very least, if you think that you might change the interface, 
> you should add in the javadoc that it might change in v2.0.
Isnt this always the case with commons? Every major release is allowed 
to introduce non backward compatible changes as long as there existed a 
migration path?

---
Mario


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