Ciao Martin, please, read below... On 8/31/07, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > Hello Simone > > > Simone Giannecchini a écrit : > > my fault I started a philosophycal discussion with these thread, > > Don't worry, I was not silent because I was upset but only because I was > finishing a work in progress. It is normal to have different views in an open > source project, and occasional philosophical discussions are probably part of > the game for a long-term project. I'm trying myself to learn which beliefs I > should stand on, and which ones are exageration of mine that I should give up. > > > >> Boolean requireGeophysicsType > >> > >> is really an implementation trick; a public API should rather use an > >> enumeration (this work was started with ViewType but not finished). > > > > I agree, but this is the implementation we have right now even if it > > may change. > > This field could be pretty useful for subclasses which may want to change > > their > > behaviour or do some preprocessing before doing the actual work. One > > example is > > applying operations that may want to expand paletted coverage. Sometimes we > > can > > apply them on the non-geo view some other on the geo view depending on > > various > > factors like interpolations and the like. Conclusion is I would leave > > it protected. > > Is the current state "This could be useful" or is it "We need it right now for > XYZ implementation"? If the need is not yet there and just a possibility that > someone may need it, maybe we could wait for the first of the following event > to > occur: 1) The need occured, or 2) We replaced the implementation trick by a > API. > I ma pretty sure this would be useful as soon as I start refactoring scale, subsample and the like as subclasses of OperationJAI. I will need the possibility to adapt/decorate JAI params as well as these facilities.
> We could do the following: if we need 'extractSources' and 'postProcessResult' > righ now, we could change the return type from Boolean to ViewType. > Go ahead on that, so that we can start talking about the ViewType work.. > > <Adding @deprecated Decorators> > > I would not use the deprecation tag until we have a replacement for > > these classes > > I'm going to take a coffee and look immediately when I'm back if we could > merge > the decorator with their parent class. > > Martin > Thanks, Simone. -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it ------------------------------------------------------- ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
