
Inline::SLang::Details - How Inline::SLang works

# # This document was added in version 0.21 of Inline::SLang and # is not complete #
This document is intended to provide details of how Inline::SLang weaves its magic. It's probably going to be most use in cases when you find apparently bizarre behaviour and wonder if it is a bug or a feature.
The implementation for Inline::SLang was initally based on the code found in Neil Watkiss' Inline::Python and Inline::Ruby modules. However, all bugs are my own creation.
If the Perl code has not been evaluated before - or if it has been changed since the previous run - the Inline code kicks in to evaluate the S-Lang code. This involves:
BIND_NS configuration option. The user-supplied S-Lang code is then evaluated and the same set of namespaces are again queried for the names of defined functions. We also pick up any new namespaces that may have been defined if the BIND_NS option is set to All.
The names of the new functions - i.e. those functions added by the user-supplied S-Lang code which the S-Lang function _apropos(), using a flag value of 3, lists - are stored for later use.
Complications are:
bind_slfuncs is added to the list of functions to bind. This list can include functions defined as part of the S-Lang Run-Time Library.typedef statement.
Utility functions are created in Perl in the Inline::SLang package which are wrappers around calls to the DataType_Type constructor. This allows users to say Inline::SLang::UShort_Type() rather than DataType_Type->new("UShort_Type").
For those types we do not recognise - essentially all user-defined types - we create objects with names equal to the S-Lang variable name.
