From uima-dev-return-9981-apmail-incubator-uima-dev-archive=incubator.apache.org@incubator.apache.org Mon Aug 10 14:32:57 2009 Return-Path: Delivered-To: apmail-incubator-uima-dev-archive@minotaur.apache.org Received: (qmail 41037 invoked from network); 10 Aug 2009 14:32:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Aug 2009 14:32:57 -0000 Received: (qmail 64965 invoked by uid 500); 10 Aug 2009 14:33:04 -0000 Delivered-To: apmail-incubator-uima-dev-archive@incubator.apache.org Received: (qmail 64934 invoked by uid 500); 10 Aug 2009 14:33:04 -0000 Mailing-List: contact uima-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: uima-dev@incubator.apache.org Delivered-To: mailing list uima-dev@incubator.apache.org Received: (qmail 64924 invoked by uid 99); 10 Aug 2009 14:33:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 14:33:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kottmann@gmail.com designates 209.85.221.192 as permitted sender) Received: from [209.85.221.192] (HELO mail-qy0-f192.google.com) (209.85.221.192) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 14:32:55 +0000 Received: by qyk30 with SMTP id 30so2568594qyk.32 for ; Mon, 10 Aug 2009 07:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=Cns/uzCVbcfbVM8KfpZv7biXDP7M2eGWa3TXc+FbpBM=; b=q/nF1v2ivUO+LgjDprNpbqn1cYRcCMuFm+RW58MZpXQRuM2KIZOfoyWYxt4BwnHtbo pQsTq7/LncHK6Q2Sg+hD+v9k5+negLsHCEBwyRXDsHa5F+LEhamwyCAVuR+QmklMhaZ6 uiaHVCzEWbyhpLz7zhelDu1tCwebXN6XnNht0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=SVZPyCcaA9o/XvePZWBvXeUJWL8LSErt8T78iFCtSxLERPapHcXdWp3IuWZd/mlV2m qPGPKCqWrHdVXxtMwMu6/HXibIr23yOz+Z0gosIEKrC0bguO7vqDi/jjEFGvArrWbAz3 tKS3hu4SysPrBszMbkI4FUwl1N1VYIEt4phyE= Received: by 10.224.19.130 with SMTP id a2mr3133346qab.312.1249914754417; Mon, 10 Aug 2009 07:32:34 -0700 (PDT) Received: from ?10.49.0.50? ([72.14.241.6]) by mx.google.com with ESMTPS id 5sm462304qwg.40.2009.08.10.07.32.32 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 07:32:33 -0700 (PDT) Message-ID: <4A802F7E.2090204@gmail.com> Date: Mon, 10 Aug 2009 16:32:30 +0200 From: =?windows-1252?Q?J=F6rn_Kottmann?= User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: uima-dev@incubator.apache.org Subject: Re: generics: getViewIterator References: <4A7C78FD.9060208@schor.com> <4A7DE6B2.2080507@schor.com> <2787e08a0908091414s5a928d81l1812492526a27806@mail.gmail.com> <4A801479.3000901@schor.com> <4A802578.8030507@gmail.com> <4A802C70.2050903@schor.com> In-Reply-To: <4A802C70.2050903@schor.com> Content-Type: multipart/alternative; boundary="------------090001010406010308030701" X-Virus-Checked: Checked by ClamAV on apache.org --------------090001010406010308030701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Marshall Schor wrote: > Jörn Kottmann wrote: > >>> Here's another (probably weak) use case for returning >> AbstractCas> kinds of things: If you have part of the code which >>> collects views and some of these views use one form of the AbstractCas >>> (e.g. CASImpl) and others use the JCas form, it would be nice to be able >>> to put these two uses into a collection (of AbstractCas) - which is the >>> kind of thing AbstractCas was trying to do, I believe. >>> >>> >> I never really understood the reason why AbstractCas exists, >> it only has a release method, but CAS and JCas have many methods in >> common. Why are they not declared in AbstractCas ? >> >> The way its now AbstractCas is nearly useless expect >> for cas pooling or so. >> >> What was the reason to not move up the common methods >> when AbstractCas was introduced ? >> > > Good question :-) -- I wasn't involved with the design here, but I can > think of 2 reasons (there may be others). (1) API stability - not > wanting to change existing APIs. I haven't studied API evolution as > much as I might, but I think this kind of change would cause a binary > incompatibility. > We can move up these methods. And yes its not binary compatible, because it breaks all implementations of AbstractCas, but in our case we could do it because the interface is not intended to be implemented by clients. Anyway we should double check this. > (2) Some methods are the same except that in the CAS they return things > of type CAS, and in the JCas they return things of type JCas. So some > kind of overloading is possible if the arguments are CAS vs JCas, but is > not possible if the returned types are CAS vs JCas. In this case, the > solution might be to return things of AbstractCas type. > Lets take the case of getViewIterator: AbstractCas: Iterator getViewIterator() throws CASException CAS: Iterator getViewIterator() JCas: Iterator getViewIterator() throws CASException I am not sure about the exception, but looks fine to me. Jörn --------------090001010406010308030701--