Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
----- Original Message ----- From: "Keith Davidson" <keith.davidson@xxxxxxxxxxxxx> To: "John Caron" <caron@xxxxxxxxxxxxxxxx> Sent: Tuesday, July 02, 2002 1:41 AM Subject: Re: request: package-private to protected > Hi John, > > Sorry to take so long getting back to you, have been busy on another project. > > The way I see it, the only reasons to ever use "package-private" instead of > "protected" is: if you want to tightly couple some classes together, and > that can be more elegantly done with inner classes now, and I dont think > that was your intention; or to simply deliberately prevent other developers > (protect them from themselves) from subclassing your classes, and I assume > that was not your intention either. Well probably that is the closest thing to an intention i had about it. Subclassing breaks encapsulation, and so subclasses can easily become dependent on implementation details that are intended to be private. Its much harder to write classes that will be subclassed. And so, I havent designed for subclassing. It would be better if I had, and I like a lot of your ideas that you mention below, but I havent yet thought hard about it. I agree inner classes are a substitute for package private. But package private is still useful, inner classes arent always the most elegent thing to do. > > Thus, my recommendation, and I hope you agree, is to change *every* > instance of "package-private" to "protected", or even "private" or "public" > if more appropriate. > > If you disagree, and still want me to send a list of required changes, then > please let me know and I'll have another look, but from memory the problem > extends through several layers of subclasses, so it may get a bit > convoluted, and I might miss something. There is also a risk that even if > you make the required changes, when I go to do something else later on, I > might need you to change something else to protected as well... I think I would need to review things, but perhaps i would come to the same conclusion. > > > > No I didn't know of ucar.nc2.VariableStandardized, thanks for the info. I > just tried to download the 2.08 javadoc and source, but keep getting a > java.util.zip.ZipException: invalid EXT descriptor signature??? I just tested it and it worked ok. Can you try again and give me details if it fails? > > > > Features I have added: > > Facilitates automatic creation of default attributes when a variable from > our conventions is created. When a new WniomNetcdfFileWriteable is > created, the current conventions file (a default is provided and > maintained), is parsed. Every time a variable is added, if the variable > name is in the convention file, then any default attributes are > automatically added. that sounds very useful > > Support for automatic scale and offset. When reading or writing data, if > the variable contains either of the "scale_factor" or "add_offset" > attributes, then scale and offset is calculated automatically. i would be interested in how this may differ from VariableStandardized > > Various convenience methods. There are various copy constructors and copy > methods, for copying entire or partial netcdf files. These don't copy the > data, just the structure. There are two write methods which can write from > native java arrays, circumventing the need to create ucar.ma2.Arrays also sound good > > To do: Implement modification and addition of dimensions, variables, and > attributes to an existing netcdf file. problem is ucar.netcdf didnt allow this, so it needs to be rewritten. > > > I am more than happy to send you the source code if you would like to have > a look. Yes, please send it. If you have any notes or summary of changes you had to make, that will be appreciated. I hope to do another round of development on it, and use the new java.nio > > > Regards, > Keith. > > PS - my colleague has asked me to pass on the following: > > In ucar.nc2.Attribute the code needs to check for the length of the string. > > public String getStringValue(){ > String v = att.getStringValue(); > > // get rid of trailing zeroes > // check size first! > if (v!=null && v.length()>0 && v.charAt( v.length()-1) == 0) > return v.substring(0, v.length()-1); > else > return v; > } i think this is fixed in latest version: public String getStringValue(){ String v = att.getStringValue(); if (v.length() == 0) return v; // fixed for zero length string - dwd // get rid of trailing zeroes if (v.charAt( v.length()-1) == 0) return v.substring(0, v.length()-1); else return v; } > > > > At 01:20 AM 4/19/02, you wrote: > >Well, the right thing to do is for me to carefully decide which methods can > >be subclassed and which not. In lieu of that hard work, perhaps you could > >send me the list of things which you found necessary to change to protected. > > > >I can understand why you need to call Variable( ucar.netcdf.Variable ncvar, > >ArrayList myDims) if you want to subclass variable. > > > >PS: do you know about ucar.nc2.VariableStandardized class which may do the > >scale and offset as you need? > > > >PPS: Id be interested in hearing a summary of the features you have added; > >perhaps i would add some into the main release if they are of general use. > > > > > > > > > >----- Original Message ----- > >From: "Keith Davidson" <keith.davidson@xxxxxxxxxxxxx> > >To: "John Caron" <caron@xxxxxxxxxxxxxxxx> > >Sent: Wednesday, April 17, 2002 9:45 PM > >Subject: request: package-private to protected > > > > > > > Hi John, > > > > > > I know this is a big ask, but I am wondering if it is possible to change > > > everything that is package-private to protected for future releases of the > > > Java NetCDF packages. This creates some difficulty for us to subclass the > > > nc2 package. I can change the source myself, and recompile it, but I have > > > to re-do it every time there is a new release. > > > > > > If you need an example of why this is required: we have implemented > > > automation of things like scale and offset on reading and writing. ie, > >all > > > the read and write operations of WniomNetcdfFile and > > > WniomNetcdfFileWriteable look for attributes called "scale_factor" or > > > "add_offset", and if they exist, perform the scale and offset operations > > > after/before reading/writing. This all works fine. However, there are > > > also read methods in the Variable class, and although I can override these > > > in WniomVariable, I can't get > >WniomNetcdfFile.findVariable(java.lang.String > > > name) to return a WniomVariable, only a Variable, because, for example the > > > Variable( ucar.netcdf.Variable ncvar, ArrayList myDims) constructor is > > > package-private, and so on... > > > > > > Thank you for your time. > > > > > > Keith Davidson > > > Software Engineer > > > WNI Oceanographers and Meteorologists > > > 31 Bishop Street > > > JOLIMONT WA 6014 > > > AUSTRALIA > > > http://www.wnise.com > > > Phone: +61 8 9387 7955 Fax: +61 8 9387 6686 thanks for your thoughtful comments!
netcdf-java
archives: