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.
You are right Chris, the original question was about whether the examples woule be changed. But since Tom's response included a commitment to not remove the deprecated pieces, I thought that as the original author of VisAD I should second our commitment to VisAD developers to not "break" applications that use our the API. Cheers, Bill On Tue, 27 Mar 2012, Chris Burghart wrote:
I thought the original question was whether the *examples* would be changed to avoid using deprecated pieces, rather than if the deprecated pieces themselves would go away. It doesn't seem too bad a task to look through the examples when deprecation occurs, and change things to use the (presumably improved) new API. But then it wouldn't be me doing it. :-) And of course, going back to fix for previous deprecations is another story... Anyway, my $0.02. Chris Bill Hibbard <bh@xxxxxxxxxxxxx> wrote: On Tue, 27 Mar 2012, Tom Whittaker wrote:There are no plans to ever remove any of the deprecated classes or methods, . . .I just want to second that. For a system like VisAD intended to support a community of application developers, we view the API as a contract with that community. It's a very bad idea to ever remove any functions or to change the meaning of any functions, because this forces the community to change their applications and because it is generally easy to avoid such forced changes by simply adding new functions to the API. Bill _____________________________________________ visad mailing list visad@xxxxxxxxxxxxxxxx For list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
visad
archives: