Because of the way that SMOP OO Bootstrap, it's important to have a very precise definition of its boot process, in order to make sure that no call using values that weren't yet defined occour, since this would probably cause a segfault.

SMOP Boot Sequence

SMOP Constant Identifiers

The constant identifiers, as its Responder Interface, use a very simplistic code to start. It uses plain libc calloc calls to initialize it, with static methods. Before the boot finishes, it is not allowed to call any method on a constant identifier. The correct way of matching a constant identifier during boot is by checking for pointer equity. This values are not subject to garbage collection.

SMOP Interpreter Instance Prototype

The prototype of the interpreter instance is the one that will enable evaluating any code. There will be no way of calling anyting in it untill the capture object is booted. But as the interpreter prototype doesn't depend on the lowlevel, it's initialized here.

SMOP Lowlevel

The smop lowlevel implements the basic default memory management mechanism of SMOP. Most of the objects will depend on it.

SMOP Lowlevel Capture Object

The other mandatory thing, besides the identifier, to every call to anything is a capture object. This lowlevel capture object is not the same as the high-level "Capture" object. It have a single responder interface taking care of it, and should probably return undef to WHAT.