Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!74.125.46.80.MISMATCH!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: sclaflin@webucator.com Newsgroups: comp.lang.java.programmer Subject: Re: Hairy generics question Date: Fri, 24 Feb 2012 14:07:28 -0800 (PST) Organization: http://groups.google.com Lines: 60 Message-ID: <7822487.176.1330121248108.JavaMail.geo-discussion-forums@vbkl3> References: <3c65271e-a388-49c9-bcc6-ca3bf274e74f@e27g2000vbu.googlegroups.com> <29108397.63.1330110725245.JavaMail.geo-discussion-forums@vbpw21> NNTP-Posting-Host: 96.227.80.185 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1330122697 11855 127.0.0.1 (24 Feb 2012 22:31:37 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 24 Feb 2012 22:31:37 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.227.80.185; posting-account=SVWHxwoAAAAHgCbAu0-fW388NuDxpM9h User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12300 On Friday, February 24, 2012 3:03:56 PM UTC-5, Lew wrote: > On 02/24/2012 11:12 AM, sclaflin wrote: > Perhaps the circularity is necessary, but I've worked with my fellows on = a few=20 > hairy generics issues where circularity seemed necessary, and it never wa= s.=20 > Each time it turned out that an acyclic type graph did the trick, and bet= ter=20 > than the initial circular approach. >=20 > Of course since you can't share any of the relevant details we have no wa= y of=20 > helping you see if there is an acyclic approach. Still, I cannot accept y= our=20 > simple declaration that there isn't. The odds are just too strongly again= st it. >=20 Lew,=20 You could well be right. I based my structure on a framework that had Pres= enter and View, but then the view didn't know how to talk to the present= er. So, they add in ReverseView

separately. I was trying to combine th= em both, and with those dual sorts of situations I've always ended up with = circularity. You guessed that I've got proprietary code that I can't share, and I'm supp= osed to be spending time on that, not general-purpose things. But, if I ca= n come up with a minimal but complete example, I'll post it.=20 > > Unfortunately, when I tried to come up with a reduced set of declaratio= ns to post, I oversimplified and left out some of the nested parametrizatio= n. And, when I went to put those back in, I realized the issue. Once I lo= ck in the base view, the V disappears. > > > > So, the real issue was not with the class that I found the error in, wh= ich was trying to use CompItemView, but in CompItemView itself, when I left= in the V parameter. It should be: > > > > public class CompItemView< > > T extends CompInfo, > > P extends AbstractCompItem>> > > extends AbstractCompItemView> > > implements CompItemViewInterface> > > > > after removing the V from the CompItemView parametrization. >=20 > That's a step in circularity reduction. How is it necessary when your own= =20 > experience shows that its removal helped? I'm confused. >=20 I have minimal circularity in the classes that finally get instantiated -- = it's the middle levels of concrete and abstract base classes that have the = hairy generic stuff. The intent of the particular code I posted was to reu= se one view class for a number of presenters where the view could render th= e bean from its toString method. But I've been operating under the belief = that I would still need to have those circular mid-level classes available = to extend matched views and presenters for unique cases.