James Carman schrieb:
On Fri, Oct 31, 2008 at 4:01 PM, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Ralph,
Ralph Goers wrote:
FWIW, I agree. I must have missed the earlier discussion as well. I
definitely prefer having an interface that can be used whenever a
specific implementation is not required.
The original arguing was, that an interface will always prevent an
enhancement because of backward compatibility. This is especially true for
the current Configuration code base.
Whenever I get a Configuration object passed, I cast it quite immediately to
an AbstractConfiguration to set the delimiter and throw mode. If
Configuration itself were an abstract class, those methods could have been
added long ago without breaking backward compatibility.
Look through the archives, the discussion with pros and cons went on
promoting commons-proxy.
Yes they did! I remember it well and I hated using a class rather
than an interface. However, I can see the merit in the decision when
it comes to maintenance and backward compatibility. As a "purist", it
just hurt! ;)
I found a reference to the original discussion. It came up when we
talked about new features for Configuration 2.0:
http://www.nabble.com/-configuration--What-changes-in-Commons-Configuration-2.0---td15530059.html
As you can see I was also pro interfaces. However the issue of backwards
compatibility is really important for projects like Commons providing
basic libraries.
I was always on the opinion that our Configuration interface is too fat.
About 80% percent of its methods actually deal with data conversion. So
my intention is to separate basic operations for accessing properties
from high-level convenience methods.
Interfaces are especially useful where you expect multiple
implementations. This is the case for the part I called
ConfigurationSource, i.e. the actual management of configuration
properties. It is not the case for stuff like data conversions. We will
implement this once and use it throughout the library. Thus it is fine
with me having a class that provides a richer API built on top of the
fundamental ConfigurationSource interface. The class merely serves as a
kind of decorator; you can still pass the ConfigurationSource objects
around, which contain the actual content.
The names I used - ConfigurationSource for the interface and
Configuration for the decorator class - may not be the best choice though.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
