[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: request: package-private to protected

----- Original Message -----
From: "Keith Davidson" <address@hidden>
To: "John Caron" <address@hidden>
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" <address@hidden>
> >To: "John Caron" <address@hidden>
> >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!