Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: blmblm@myrealbox.com Newsgroups: comp.lang.java.programmer Subject: Re: generics puzzle Date: 25 Nov 2011 17:46:10 GMT Organization: None Lines: 70 Message-ID: <9ja2j1Fmj4U1@mid.individual.net> References: <9g2f24Fi0vU1@mid.individual.net> <9g5nnhFahuU1@mid.individual.net> <9g5salFh1jU2@mid.individual.net> <9g81fmFj6eU2@mid.individual.net> X-Trace: individual.net kRssNJIVvKMpveiGAOa3YgJYteWNpPBRKGkRap+u4v58iDNyMc X-Orig-Path: not-for-mail Cancel-Lock: sha1:p2JPGotr3Lg/cnji9DIklryN9jY= X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10226 In article <9g81fmFj6eU2@mid.individual.net>, blmblm@myrealbox.com wrote: > In article <9g5salFh1jU2@mid.individual.net>, > blmblm@myrealbox.com wrote: > > In article <9g5nnhFahuU1@mid.individual.net>, > > Robert Klemme wrote: > > > On 10/18/2011 04:49 PM, blmblm@myrealbox.com wrote: > > > > In article<45bfae98-a142-469b-9b8b-9aa8a59391f1@n13g2000vbv.googlegroups.com>, > > > > Robert Klemme wrote: > > > >> On Oct 17, 12:41 pm, blm...@myrealbox.com > > > >> wrote: > > [ snip ] > > > > >> In your case since apparently you want to update internally why not > > > >> just introduce > > > >> > > > >> public void update() { > > > >> set(modified()); > > > >> } > > > > > > > > I'm not sure I can say why this doesn't appeal to me -- something > > > > about not wanting to clutter up GThing with unnecessary methods. > > > > > > Why is it unnecessary? It seems this provides a proper abstraction. As > > > your example shows and concluding from what you write below you do > > > already have two or more uses for it. So by having the method you can > > > actually reduce redundancy. That's a common pattern: we find we do > > > something over and over again, we turn it into a method or procedure. > > > > Yeah, maybe. I'll look some more at my actual code. > > > > > >> This will safely compile. Basically this is what you did with > > > >> setModified() in the wrapper class. All other approaches will be > > > >> hacky (i.e. involve explicit casting, using Object parameters or > > > >> return values etc.). > > > > > > > > Yeah, maybe .... In my "real" code (quotation marks because it's > > > > a toy project embarked on for entertainment and a bit of education) > > > > the method in the wrapper class does more than just call modified() > > > > and then set(). I don't know that that matters much, though. > > What may matter, though, is that sometimes I want to immediately > pass the value returned by modified() to set(), while other times > I want to save the value returned by modified() locally, from where > it might or might not later be passed to set(). > > My most recent refactoring of the "real" code uses static generic > methods (as suggested somewhere upthread), and for now that seems > not-bad. I'll probably change my mind again at some point. :-)? > And I did, so -- a very belated follow-up, for the record maybe .... Eventually, after much rearranging of the furniture, I came around to the idea that maybe it did make more sense to put the desired functionality in GThing. In my "real" application I wanted to be able to compute a possibly-temporary result and then later optionally save it. What I ended up doing was storing the possibly-temporary value in the GThing (rather than returning it for the caller to keep track of) and adding a method to GThing to save the possibly-temporary value. There are still some things about this setup and how it fits into the overall application that feel like ugly hacks, but the application does what I wanted it to do, and at some point one has to say "good enough for now" and move on, maybe. -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.