Steven A Rowe wrote:
In the comments on the blog post, the author (Kirill Osenkov) agrees with a dissenter
(Alexander Jung, a.k.a. "AJ.NET"), who re-states the rule of thumb as:
"An interface should define at most one contract."
But what if you want to expand the contract? For example, Field was
initially just <String,String>, a fine contract. Field has been
generalized to be <String,String|Bytes|Reader|TokenStream>, all without
breaking applications. While in hindsight this evolution may seem
obvious, no one forsaw it. APIs that are too general are confusing.
It's best to be clear about what's supported and what's not. Over time,
one may add more features, generalize, introduce new levels of
indirection, etc., as demand warrants. It is impossible to know which
APIs will grow in advance, and wrong make them overly general from the
start. So they must evolve. But if you break applications in the
process you waste too much of your time responding to confused users
instead of making progress. Also, happy users lead to more contributors
and a stronger project. Interfaces do little to help this process and
much to hinder it.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
