From rgentlem at fhcrc.org  Thu Apr 27 17:17:22 2006
From: rgentlem at fhcrc.org (Robert Gentleman)
Date: Thu, 27 Apr 2006 08:17:22 -0700
Subject: [Rd] proposed modifications to deprecated
Message-ID: <4450E082.5010206@fhcrc.org>

Hi,
   Over the past six months we have had a few problems with deprecation 
and Seth Falcon and I want to propose a few additions to the mechanism 
that will help deal with cases other than the deprecation of functions.

  In the last release one of the arguments to La.svd was deprecated, but 
the warning message was very unclear and suggested that in fact La.svd 
was deprecated.
   Adding a third argument to .Deprecated, msg say (to be consistent 
with the internal naming mechanism) that contains the message string 
would allow for handling the La.svd issue in a more informative way. It 
is a strict addition so no existing code is likely to be broken.

   We also need to deprecate data from time to time. Since the field of 
genomics is moving fast as good example from five years ago is often no 
longer a good example today. This one is a bit harder, but we can modify
   tools:::.make_file_exts("data")

   to first look for a ".DEP" extension (this does not seem to be a 
widely used extension), and if such a file exists, ie NameofData.DEP
  one of two things happens: if it contains a character string we use 
that for the message (we could source it for the message?), if not print 
a standard message (just as .Deprecated does) and then continue with the 
search using the other file extensions.

   Defunct could be handled similarly.

  Comments, alternative suggestions?

  thanks
    Robert

-- 
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
rgentlem at fhcrc.org



[Rd] proposed modifications to deprecated
Robert Gentleman