Project

General

Profile

Bug #34

CoCoAManual: obsolete entries in the manual

Added by Anna Maria Bigatti over 12 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Manual/documentation
Target version:
Start date:
22 Nov 2011
Due date:
% Done:

100%

Estimated time:
15.00 h
Spent time:

Description

Some functions and commands are now obsolete ("Delete", "Call", ...).
The related entry (with searchable "<key>") should be part of a section "Obsolete Functions and Commands" with motivation and instructions for conversion (if any)


Related issues

Related to CoCoA-5 - Support #177: CoCoAManual: General part of the documentation is obsolete: update? discard?In Progress2012-06-01

Related to CoCoA-5 - Support #488: CoCoAManual: Help page for porting old C4 code to C5Closed2014-03-21

History

#1 Updated by Anna Maria Bigatti over 12 years ago

  • Project changed from CoCoA to CoCoA-5

#2 Updated by Anna Maria Bigatti over 12 years ago

  • Subject changed from obsolete entries in tha manual to obsolete entries in the manual
  • Category set to Manual/documentation

#3 Updated by Anna Maria Bigatti about 11 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

fixed some uppercase/lowercase entries for make texdoc

#4 Updated by Anna Maria Bigatti about 10 years ago

  • Target version set to CoCoA-5.1.0 Easter14

#5 Updated by John Abbott about 10 years ago

  • Target version changed from CoCoA-5.1.0 Easter14 to CoCoA-5.1.1 Seoul14

#6 Updated by Anna Maria Bigatti almost 10 years ago

  • Subject changed from obsolete entries in the manual to CoCoAManual: obsolete entries in the manual
  • Status changed from In Progress to Resolved

I added the key "obsolete".
now

? obsolete

gives the list of obsolete commands (which usually give motivation and modern alternatives)
Is that good enough?
I might be able to make a "Obsolete Functions and Commands" page.... maybe....

#7 Updated by Anna Maria Bigatti almost 10 years ago

Anna Maria Bigatti wrote:

I added the key "obsolete".
now
[...]
gives the list of obsolete commands (which usually give motivation and modern alternatives)

Now I think of removing the key obsolete and just add (obsolete) to the title: it would work for the search and would be more evident (and visible in the index)

#8 Updated by John Abbott almost 10 years ago

I think your suggestion is a good one.

I propose adding OBSOLETE (in capitals) as the first word of the title; that should make it highly visible (and probably a bit ugly, but that could be a "feature" :-))

#9 Updated by Anna Maria Bigatti almost 10 years ago

John Abbott wrote:

I propose adding OBSOLETE (in capitals) as the first word of the title;

I made it all capital, but as the last word of the title (to keep alphabetical order)

#10 Updated by Anna Maria Bigatti almost 10 years ago

  • % Done changed from 10 to 50

#11 Updated by Anna Maria Bigatti almost 10 years ago

  • Status changed from Resolved to Feedback
  • % Done changed from 50 to 80

Done. Rule for maintaining it.
(1) Add [OBSOLETE] or [OBSOLESCENT] in the title of obsolete/obsolescent functions, possibily giving motivation/instructions/examples on how to update.
(2) search in CoCoA-5 for "? obsolete" will automatically give the list of obsolete functions
(3) New chapter "Migrating from CoCoA-4 and keeping up-to-date" should give general information of major changes, and also (automatically) list all obsolete and obsolescent functions

#12 Updated by Anna Maria Bigatti almost 10 years ago

Remember that obsolescent functions should be moved to the package obsolescent.cpkg5.
Now they all works silently.
Should they issue a warning in the last year before being removed?

#13 Updated by John Abbott almost 10 years ago

Yes, obsolescent functions should give some warning that they are going to disappear (and presumably what to do instead -- perhaps in the manual page?).

One problem with warnings (e.g. forgetting a ref when calling append) is that you can get hundreds of messages appearing if you call the function in a loop. While this may encourage some users to revise their code, it could also really annoy others (e.g. me).

In summary: yes, there should be warnings about obsolescent functions, but not too many of them.

Perhaps warnings should not be printed immediately, but saved up until the next prompt, and then printed (perhaps with a repeat count?)

FURTHER THOUGHTS the message warning about obsolescence should look like a warning (e.g. starting with the string WARNING:)

#14 Updated by John Abbott over 9 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 80 to 100

Also available in: Atom PDF