Language change proposal
Sat Oct 25 00:27:38 CEST 2003
Bengt Kleberg wrote:
> WILLIAMS Dominic wrote:
>> 2) Functions would be deprecated by adding an obsolete attribute that
>> would list obsolete functions in the same format as export/import:
> 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
> -obsolete(b/2, "use c/2 instead").
> moreover, eiffel can obsolete a whole class. which could be quite handy:
> -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
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
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
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.
More information about the erlang-questions