[Suggestion] More deprecation features

[Robert Fraser]

Stewart Gordon Wrote:

> Now that most of the rusty old deprecation bugs have finally been squashed 
> (if you'll excuse the mixed metaphor), here are a few ideas I've had for a 
> while for taking the concept of deprecation further.
> 
> 
> 1. Sometimes it's useful to deprecate something, but keep it for internal 
> use.  So effectively it's private, except if compiling with -d, in which 
> case it will be public.  The notation might look something like
> 
>     private deprecated public void qwert() { ... }
> 
> The error message on trying to use it from outside might look something like
> 
>     qwert.d(42): function qwert is deprecated for public access
> 
> Other combinations of access levels would be similarly allowed, of which 
> these make sense IMM:
> 
>     private deprecated package
>     private deprecated protected *
>     private deprecated public *
>     private deprecated export *
>     package deprecated public *
>     package deprecated export *
>     protected deprecated public
>     protected deprecated export
>     public deprecated export
> 
> Overriding of methods with the asterisked protection settings would be 
> allowed only if the derived class method is also deprecated (or -d is 
> specified).  To declare a method with the same name and parameters in a 
> derived class, without specifying either the deprecated attribute or the -d 
> switch, would be an error.  This is necessary to the principle of 
> deprecation, i.e. code that compiles without -d doesn't change its behaviour 
> when -d is specified, and existing code can still compile.
> 
> Of course, implementing this would affect how attributes are parsed.  I 
> suppose the best idea would be to treat each possible case of the word 
> "deprecated" immediately between two protection attributes as a protection 
> attribute in its own right in terms of the way they override each other.
> 
> 
> 2. A means of deprecating callbacks.  That is, deprecating overriding of a 
> method rather than using it.  This makes sense as callbacks are going to 
> want replacing from time to time, just as callforwards :-) are.  The base 
> class would keep its calls to the method, so that old code will still work, 
> but new or modernised code would not be overriding it anymore.
> 
> (This would be provided at least to some extent by idea 1....)
> 
> 
> 3. Deprecating modules.  Currently, the compiler doesn't allow modules to be 
> declared as deprecated.  A module being deprecated may signify:
> 
> - that the whole API area that it is there to support is deprecated, either 
> because it's an obsolete technology or because it's been superseded by 
> another module
> 
> - that the module has been renamed, and all the old one does is imports the 
> new one for compatibility
> 
> - that it was used for development/testing purposes and is no longer needed
> 
> 
> 4. Deprecated imports.  So effectively, any attempt to use anything from the 
> imported module would throw a deprecation error, unless a non-deprecated 
> import of the same module is also visible from the scope where the use 
> occurs.  This might be to prevent the compiler error that would otherwise be 
> caused by importing a deprecated module for use by deprecated code.  Or to 
> phase out a public import that was figured to be a bad idea.
> 
> 
> Comments?
> 
> Stewart.
> 
> -- 
> My e-mail address is valid but not my primary mailbox.  Please keep replies 
> on the 'group where everybody may benefit. 
> 

All good ideas, but I fear that it's simply too much complication to make it 
worth doing.