Alexandre Vassalotti writes: > Perhaps, it would be a good idea to take Plan9's approach to > portability -- i.e., you develop an extreme allergy to code filled > with #if, #ifdef, #else, #elseif; localize system dependencies in > separate files and hide them behind interfaces.
If I understand correctly, Emacs uses this approach (although not thoroughly). The resulting portability files are called s & m files for several reasons. One of course is that they are kept in subdirectories called "s" for "system" and "m" for "machine". The more relevant here is the pain they inflict on developers, because they make it more difficult to find implementations of functions, and hide (or at least distribute across many files) potentially relevant information. Although parsing a deep #ifdef tree is very error-prone and annoying, this can be improved with technology (eg, hideif.el in Emacs). The #ifdef approach also has an advantage that all alternative implementations and their comments are in your face. Mostly they're irrelevant, but often enough they're very suggestive. Though I suppose a sufficiently disciplined programmer would think to use that resource if split out into files, I am not one. This is an important difference between the approaches for me and perhaps for others who only intermittently work on the code, and only on parts relevant to their daily lives. In the end, the difference doesn't seem to be that great, but for us preferred practice (especially as we add support for new platforms) is definitely to put the platform dependencies into configure, to try to organize them by feature rather than by cpu-os-versions-thereof, and to use #ifdefs. FWIW YMMV. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
