Documented in-memory parse feature.
1 parent dd52726 commit de1cde47ab8671e4811ebb8ed067da71d9484854
@tundra tundra authored on 14 Jan 2005
Showing 1 changed file
View
26
WHATSNEW.txt
CHANGES
 
- The program changes described below have made the 'ParseConfig'
API incompatible with previous versions of 'tconfpy'. The version
number has been branched to 2.x to reflect this fact. Existing
programs that use 'tconfpy' will have to be modified to use
this new release.
 
- Symbol Tables and Templates are now first-class objects in their own
right (classes 'SymbolTable' and 'Template' respectively). This
means API will not be compatible with programs built using previous
 
- The 'RetObj' object has been removed. Objects of type 'SymbolTable'
are now returned.
 
- Significant internal code resturcturing to encasulate parse-related
data structures into the 'Symbol Table' object. This eliminated
most of the global variables.
- There is significant internal code restructuring to encasulate
parse-related data structures into the 'SymbolTable' object. This
eliminated most of the global variables.
 
- Template variables previously required a right hand side when
instantiated. It is now possible to have a construct like
"TemplateVariable=" in the configuration file. In that case, the
- Added the 'CallingProgram' API keyword parameter. This allows the
calling program to change the program name embedded in every message
produced during the parse.
 
 
- It is now possible to parse a configuration that is stored in-memory
as a list of text lines. The 'ParseConfig' API "autodetects" whether
it is parsing a file or an in-memory list by examining the type of
the first (mandatory) parameter passed to it. If it is a string,
the program assumes it to be a file name. If it is a list, the
program assumes the list contains configuration statements. If it
is of any other type, the program declares an error.
 
 
WHATSNEW For 'tconfpy' 1.185 (Sun May 2 03:07:05 CDT 2004)
----------------------------------------------------------------------