SMOP Constant Identifiers: Revision 7
As everything in SMOP is an object, including the method identifiers in the messages to the SMOP Responder Interface s, we need them to be defined with a special responder interface that can be created at the very early stage of smop initialization. These constants are not subject to garbage collection, and must always be freed when no more needed. Fortunally their usage is considerably controlled, and at this point there's a single point of initialization and destruction of the constants.
See include/smop_identifiers.h for the list of constants.
The header file is used by the identifiers2C.pl script to automatically create the initi and destr code for each of this identifiers. This code is saved in src/idconst_decl_all.h, src/idconst_init_all.c and src/idconst_destr_all.c which are included in src/idconst.c.
Defining new constants at runtime
One important thing to realise about declarations is that they will survive most of the time until global interpreter destruction. All barewords will be at least referenced by the AST objects or by the OpTree objects of the interpreter. This means that managing garbage collection for this constant values is a waste of time, and possibly maintaining several copies of the same constant value is a waste of memory space. And more importantly, constant values being unique, reduce the comparing, which usually would end up being a function call to a simple C pointer identity check.
The C api is:
SMOP__Object* SMOP__NATIVE__idconst_create("foo"); SMOP__Object* SMOP__NATIVE__idconst_createn("foo",3);
This will check if there's already a constant defined with that content, create a new one if not and return a previously existing one when available. the destruction of this constant values will take place during global destruction, which means that you should only declare values that would already be destroyed very late, or for values which could potentially be excessively recreated over and over again.
Declaring new constants will eventually mean re-sorting the list that holds all the constants. Most of the time, you'll want to do that declarations at BEGIN time and eventually try to promote the constant to be part of the SMOP Boot Sequence, instead of doing runtime declaration.