Mercurial > emacs
annotate admin/notes/iftc @ 83474:d08a7ef0cb8a
Merged from emacs@sv.gnu.org
Patches applied:
* emacs@sv.gnu.org/emacs--devo--0--patch-91
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-92
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-93
Merge from gnus--rel--5.10
* emacs@sv.gnu.org/emacs--devo--0--patch-94
Merge from gnus--rel--5.10
* emacs@sv.gnu.org/emacs--devo--0--patch-95
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-96
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-97
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-98
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-99
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-100
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-101
Update from CVS
* emacs@sv.gnu.org/emacs--devo--0--patch-102
Merge from erc--emacs--0
* emacs@sv.gnu.org/emacs--devo--0--patch-103
Update from CVS: src/regex.c (extend_range_table_work_area): Fix typo.
* emacs@sv.gnu.org/emacs--devo--0--patch-104
Update from CVS
* emacs@sv.gnu.org/gnus--rel--5.10--patch-30
Merge from emacs--devo--0
* emacs@sv.gnu.org/gnus--rel--5.10--patch-31
Update from CVS
* emacs@sv.gnu.org/gnus--rel--5.10--patch-32
Update from CVS
* emacs@sv.gnu.org/gnus--rel--5.10--patch-33
Update from CVS
* emacs@sv.gnu.org/gnus--rel--5.10--patch-34
Update from CVS
* emacs@sv.gnu.org/gnus--rel--5.10--patch-35
Merge from emacs--devo--0
* emacs@sv.gnu.org/gnus--rel--5.10--patch-36
Update from CVS
git-archimport-id: lorentey@elte.hu--2004/emacs--multi-tty--0--patch-514
| author | Karoly Lorentey <lorentey@elte.hu> |
|---|---|
| date | Mon, 20 Feb 2006 16:30:15 +0000 |
| parents | 695cf19ef79e |
| children | 375f2633d815 ef719132ddfa |
| rev | line source |
|---|---|
| 45625 | 1 Iso-Functional Type Contour |
| 2 | |
| 3 | |
| 4 This is a term coined to describe "column int->float" change approach, and can | |
| 5 be used whenever low-level types need to change (hopefully not often!) but the | |
| 6 meanings of the values (whose type has changed) do not. | |
| 7 | |
| 8 The premise is that changing a low-level type potentially means lots of code | |
| 9 needs to be changed as well, and the question is how to do this incrementally, | |
| 10 which is the preferred way to change things. | |
| 11 | |
| 12 Say LOW and HIGH are C functions: | |
| 13 | |
| 14 int LOW (void) { return 1; } | |
| 15 void HIGH (void) { int value = LOW (); } | |
| 16 | |
| 17 We want to convert LOW to return float, so we cast HIGH usage: | |
| 18 | |
| 19 float LOW (void) { return 1.0; } | |
| 20 void HIGH (void) { int value = (int) LOW (); } /* iftc */ | |
| 21 | |
| 22 The comment /* iftc */ is used to mark this type of casting to differentiate | |
| 23 it from other casting. We commit the changes and can now go about modifying | |
| 24 LOW and HIGH separately. When HIGH is ready to handle the type change, the | |
| 25 cast can be removed. | |
| 52401 | 26 |
| 27 ;;; arch-tag: 3309cc41-5d59-421b-b7be-c94b04083bb5 |
