didnt find where you asked for comments
here are the decision i made in TriX to clearly distinguish beween scripting and internal functions.
maybe they are a good starting point as they were quite good to handle and stable for the script developers.
a) all public scripting API functions are in UpperCamelCase and are
documented!
(if it is an API function, it will only be UpperCamelCase if there is some documentation)
b) all core-internal functions are available as they are named in core, just with "__" prefix (e.g. __internal_function)
c) core-internal functions get replaced step by step with public scripting API
the public scripting API was handled by wrapper-functions that abstracted some internal stuff and called the __internal_function.
any change to internal functions - i.e. adding/removing parameters etc was handled by the wrapper function.
most of the stuff was autogenerated with scripts and made visible using includes.
e.g. see the partially autogenerated util.h file
http://svn.g3gg0.de/svn/default/trunk/nokia/TriX/include/auto_util.h#define UTIL_AUTO_IMPORTSdefines all functions that are visible to the scripting engine
#define UTIL_AUTO_MISC_POSTdefines the public API with all stuff necessary to make the API sane and call the internal functions.
advantage: - all core symbols are visible to scripting engine without any restriction
therefore core code is accessible - this is an exceptional case and not recommended
(e.g. bmp_printf is exported into scripting engine as __bmp_printf)
- keeping the API stuff in scripting-headers only, not affecting ML core, only scripts include that API file.
(e.g. BmpPrintf is a static inline function in scripts/include/bmp.h and calls __bmp_printf)
