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.
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.
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: