1 --- !ditz.rubyforge.org,2008-03-06/issue
2 title: Consider splitting library implementation into several source files
7 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
10 creation_time: 2009-02-07 22:14:47.776655 Z
13 id: 752bbff07353ec14321966b7c65d94f988da040b
15 - - 2009-02-07 22:17:36.252548 Z
16 - David Hilvert <dhilvert@auricle.dyndns.org>
19 New source units could perhaps include, among other things, alignment,
20 rendering, frames, and approximations. Namespace issues might have to be
21 resolved. (What to call functions intended for use solely within the library?
23 - - 2009-02-07 23:49:08.121699 Z
24 - David Hilvert <dhilvert@auricle.dyndns.org>
27 Most convenient might be to include all top-level functions (i.e., those in
28 ale.h) in libale.c, and to perhaps relegate certain other helper functions to
29 separate source files. In this way, macro construction and namespace issues
30 would likely be kept relatively simple, while some degree of complexity hiding
32 - - 2009-02-08 05:21:49.058682 Z
33 - David Hilvert <dhilvert@auricle.dyndns.org>
36 Revise title to better reflect the currently-planned architecture. (libale.c
37 remains; no immediate plans for a new common header).
38 - - 2009-02-08 18:48:01.852908 Z
39 - David Hilvert <dhilvert@auricle.dyndns.org>
42 Note that the most straightforward approach would probably be to just add
43 *_valid() to the public API, and to separate functions by task (alignment,
44 rendering, etc.) or so.
45 - - 2009-02-08 21:24:23.438216 Z
46 - David Hilvert <dhilvert@auricle.dyndns.org>
47 - closed with disposition fixed
48 - libale.c has been split by object type and task.