Having implemented an include mechanism, and a main javascript code template, it made sense to develop a standard include-file template as well. When starting to do so, I took the time to tidy up the original code template, including standardising a certain amount of descriptive documentation.

One thing that became clear was that the amount of comments et.c. added significantly to the size of an included file. As a result, I decided to provide a method for removing this overhead, in the form of a 'cleaned' include file, stripped of comments and extraneous whitespace. A 'clean' include file would be file-suffixed '.h.js', and the 'full' version, used for code maintenance would retain the '.js' suffix. The original include code was modified to use a 'clean' include file first, if present, or, in its absence, the 'full' version.

To simplify the process of 'cleaning' header files, a simple perl utility, called strippa was written capable of generating a 'clean' include file from every javascript file in directory. The utility is also capable of modifying the self-reporting 'post' messages in include files.

The revised requirements for an include file are thus:

Requirements:

• The same code fragment for the function include() must be present in javascript using includes.
• Include files with comments should be named in the form name.js.
• Include files with comments should contain the start and end lines
  post("included IOletHandler.js\n");
  and
  post("including IOletHandler.js\n");
  to aid in debugging
• Streamlined include files, cleaned of comments etc should be named in the form name.h.js.
• Include files without comments should contain the start and end lines
  post("included IOletHandler.h.js\n");
  and
  post("including IOletHandler.h.js\n");
  to aid in debugging

A basic #include type functionality was implemented to allow the easier and more modular development of Javascript within MAX/MSP. This would allow the use of reusable Javascript code in a clean and straightforward fashion,

The #include functionality was modelled after the C preprocessor, allowing the inclusion of local Javascript files as well as those in a central 'library' location (chosen to be %MAXROOT%/Cycling '74/jsincludes)

Requirements:

• The same code fragment for the function include() must be present in javascript using includes.
• Include files should be named in the form name.h.js.
• Include files should contain the start and end lines
  post("included IOletHandler.h.js\n");
  and
  post("including IOletHandler.h.js\n");
  to aid in debugging

The use of this mechanism is as follows
includes = ""; clear include buffer
include("<library>"); loads library.h.js from %MAXROOT%/Cycling '74/jsincludes/
include("local"); loads local.h.js from same folder as parent .js file
eval(includes); interprets the code
includes = ""; frees up buffer

This code should have been fairly straightforward, but issues with line-end characters caused a certain amount of headscratching. The current code, which grabs lines one at a time, might be slower, but it more forgiving of EOL issues. The implementation reads all the included module code into a single buffer then evals() it. That uses a higher memory footprint, but less processing overhead.