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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
