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