Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 19403 invoked from network); 24 Mar 2008 23:21:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Mar 2008 23:21:14 -0000 Received: (qmail 69717 invoked by uid 500); 24 Mar 2008 23:21:07 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 69675 invoked by uid 500); 24 Mar 2008 23:21:07 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 69664 invoked by uid 99); 24 Mar 2008 23:21:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Mar 2008 16:21:07 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [76.96.30.17] (HELO QMTA10.emeryville.ca.mail.comcast.net) (76.96.30.17) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Mar 2008 23:20:15 +0000 Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 5BHr1Z0030mlR8UAA00800; Mon, 24 Mar 2008 23:20:14 +0000 Received: from [192.168.168.107] ([76.103.181.218]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 5BLU1Z0094j7bz88X00000; Mon, 24 Mar 2008 23:20:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=oSDe1HvKlI980wf9jKEA:9 a=B2rkSRf2Y23CGAcgb9Y3h1i__SgA:4 a=v-5vGKKPNPAA:10 a=ufO146cb3fEA:10 Message-ID: <47E8373D.9050203@apache.org> Date: Mon, 24 Mar 2008 16:20:29 -0700 From: Doug Cutting User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: java-dev@lucene.apache.org Subject: Re: Fieldable, AbstractField, Field References: <9294E20AED46934EA459020706463F94A0401D@SUEXCL-02.ad.syr.edu> In-Reply-To: <9294E20AED46934EA459020706463F94A0401D@SUEXCL-02.ad.syr.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 , a fine contract. Field has been generalized to be , 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: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org