NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Not possible, or at least very impractical. The 'types' that Kevin and I are discussing are VisAD MathTypes and there are an infinite number of them that may be generated by applications dynamically at run time. When an application opens a file that operation may return any of those MathTypes, and other operations can generate arbitrarily complex MathTypes. Catching MathType mismatch errors at compile time would limit the compiled code to a finite set of MathTypes. VisAD does use interfaces extensively. Data, Display, Field, Cell and DataReferences are a few examples. Bill On Fri, 26 May 2006, Eric Davies wrote: > Just a thought for the future: > > Why isn't the error that Kevin experienced a compile time error > instead of a runtime error? > > At a high level, this is a type mismatch error and Java is a very > strongly typed language, suggesting that its compile time type > checking system should be usable to enforce such. > Using interfaces to clarify input arguments would serve as automatic > documentation as to what the input arguments were actually allowed to be. > Possible? ============================================================================== To unsubscribe visad, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ==============================================================================
visad archives: