Language change proposal

[Joachim Durchholz]

Bengt Kleberg wrote:
> WILLIAMS Dominic wrote:
> ...deleted
> 
>> 2) Functions would be deprecated by adding an obsolete attribute that
>>    would list obsolete functions in the same format as export/import:
>>
>> -module(my_module).
>> -export([a/1,b/2,c/3]).
>> -obsolete([b/2]).
> 
> the eiffel keyword ''obsolete'' has an argument that explains what 
> alternatives there are, instead of the obsolete feature. perhaps 
> somehting like this (yes, i know this makes it impossible to obsolete a 
> whole slew of functions in one go. but see my second example for an 
> alternative):
> 
> -module(my_module).
> -export([a/1,b/2,c/3]).
> -obsolete(b/2, "use c/2 instead").
> 
> moreover, eiffel can obsolete a whole class. which could be quite handy:
> 
> -module(my_module).
> -obsolete("use my_other_module instead").

I have been programming in Eiffel for several years, so some experience 
reports may be in order.

1. In Eiffel, the "obsolete" keyword has no semantic effect whatsoever. 
However, the Eiffel compiler will emit a warning whenever it sees a call 
to an obsolete feature. (One thing that could have been improved: if an 
obsolete routine called another obsolete routine, that call would also 
be flagged with a warning. Presumably, such calls should /not/ be 
marked... but that's really a minor nit to pick.)
An important point is that the remark given with the "obsolete keyword" 
is given as part of the warning message. The programmer will see the 
warning and can decide immediately whether anything should be done about 
the issue, without having to go into the source code of the obsolete 
function.

2. For library designers, "obsolete" is a godsend. It will deflect most 
bug reports, change requests, and other communication from application 
programmers even before it hits the support line. If a programmer ever 
has a problem with an obsolete routine, he will prefer upgrading to the 
"approved" routines to any support calls.
(Of course, some people will call anyway. But the support load reduces 
substantially.)

3. For application programmers, "obsolete" is a godsend as well. The 
remark on the "obsolete" keywords usually gives enough information that 
he knows what to do, without bothering to call support (and wait until a 
solution is available).

4. A warning to library developers: don't expect to ever get rid of a 
function marked obsolete anyway. There will be software that has been 
running untouched for a decade, and that will continue for decades to 
come. Functions marked obsolete are still there to stay, just like 
Fortran ;-)
If you want to really phase out some function, use a mechanism that goes 
beyond "obsolete", or add an option that turns the warning into 
something more severe. Or make the standard obsolescence warnings be 
emitted as "remark" and turn it into a "warning" when phasing out the 
function is imminent for the next release. Or whatever - in any case, 
provide for a distinction between mild obsolescence reminders and stern 
warnings that a function Won't Be Available Anymore.

Regards,
Jo