Re: [Geotools-devel] Feeback on the MapContext refactor

2010-06-14 Thread Andrea Aime
Jody Garnett ha scritto: > On 14/06/2010, at 4:52 PM, Andrea Aime wrote: > >> Jody Garnett ha scritto: Please don't add a layer.dispose() method, resources to be disposed are harder to use so let's limit the usage of dispose/close methods to cases where it's really necessary to

Re: [Geotools-devel] Feeback on the MapContext refactor

2010-06-14 Thread Jody Garnett
On 14/06/2010, at 4:52 PM, Andrea Aime wrote: > Jody Garnett ha scritto: >>> Please don't add a layer.dispose() method, resources to be disposed >>> are harder to use so let's limit the usage of dispose/close methods >>> to cases where it's really necessary to do so (file, streams, >>> database co

Re: [Geotools-devel] Feeback on the MapContext refactor

2010-06-14 Thread Ben Caradoc-Davies
On 14/06/10 14:52, Andrea Aime wrote: >>> I also see code that has just been commented out like in >>> FeatureSourceMapLayer, bad practice... well, unless you noted down >>> all the code that you've commented out and will remove it later. >> That will be one of the last things I do; remember up to

Re: [Geotools-devel] Feeback on the MapContext refactor

2010-06-13 Thread Andrea Aime
Jody Garnett ha scritto: >> Please don't add a layer.dispose() method, resources to be disposed >> are harder to use so let's limit the usage of dispose/close methods >> to cases where it's really necessary to do so (file, streams, >> database connections and so on). Swing does not have a "dispose(

Re: [Geotools-devel] Feeback on the MapContext refactor

2010-06-13 Thread Jody Garnett
Thanks for the feedback Andrea! Some comments inline... On 14/06/2010, at 6:18 AM, Andrea Aime wrote: > Map -> "really bad name" (tm), we should not clash with > java own classes (yes, packages keep them apart, > but code completion gets confusing) Agreed. Solution - I am thinkin

[Geotools-devel] Feeback on the MapContext refactor

2010-06-13 Thread Andrea Aime
Hi, I'm skimming through the proposal quickly and noting down the things that do look odd. Premise: the work looks sound and should clean up things significantly. I like it, past some issues I'm going to list in this mail. Map -> "really bad name" (tm), we should not clash with java own