view admin/notes/iftc @ 101600:10d6e33982c3

(todo-insert-item-here): Prevent insertion of a new entry inside of an existing entry. Minor code cleanup. (todo-add-category): Change the interactive spec. Signal an error if the Todo file is non-empty but contains no category. Reject category names that could induce bugs and confusion. Call todo-mode if the Todo file is new and unsaved. Simplify handling of local variables cookie. Properly display the newly added category in Todo mode. (todo-show): Call todo-initial-setup only if there is neither a Todo file nor a corresponding unsaved buffer. (todo-category-alist): Delete function. (todo-completing-read): New function. (todo-insert-item, todo-jump-to-category): Use it. (todo-insert-item): Make the use of the prefix argument conform to the doc string.
author Chong Yidong <cyd@stupidchicken.com>
date Wed, 28 Jan 2009 03:56:18 +0000
parents 695cf19ef79e
children 375f2633d815 ef719132ddfa
line wrap: on
line source

Iso-Functional Type Contour


This is a term coined to describe "column int->float" change approach, and can
be used whenever low-level types need to change (hopefully not often!) but the
meanings of the values (whose type has changed) do not.

The premise is that changing a low-level type potentially means lots of code
needs to be changed as well, and the question is how to do this incrementally,
which is the preferred way to change things.

Say LOW and HIGH are C functions:

  int LOW (void) { return 1; }
  void HIGH (void) { int value = LOW (); }

We want to convert LOW to return float, so we cast HIGH usage:

  float LOW (void) { return 1.0; }
  void HIGH (void) { int value = (int) LOW (); }  /* iftc */

The comment /* iftc */ is used to mark this type of casting to differentiate
it from other casting.  We commit the changes and can now go about modifying
LOW and HIGH separately.  When HIGH is ready to handle the type change, the
cast can be removed.

;;; arch-tag: 3309cc41-5d59-421b-b7be-c94b04083bb5