Related to #4186.
Some notable changes:
- The term 'Error' now strictly refers to native Error objects defined in
the ECMA standard, which are ordinary objects. All other uses of
'error' or 'error reference' where the term refers to a thrown value is
now called 'exception'.
- Simplified the naming scheme of many String API functions. These functions
will now also take an 'encoding' argument to specify the desired
encoding in which to operate.
- Removed the substring-copy-to-buffer functions. These functions
behaved awkwardly, as they use character index to specify the
start/end positions, and were mostly used incorrectly with byte
offsets instead. The functionality can still be replicated with
other functions if necessary.
- String-to-buffer functions will no longer fail if the buffer is not
sufficiently large, the string will instead be cropped.
- Fixed the usage of the '_sz' prefix in many API functions. The term
'sz' means zero-terminated string in hungarian notation, this was
used incorrectly in many cases.
- Renamed most of the public API functions to have shorter, more on-point
names, rather than the often too long descriptive names. Functions are now
also grouped by the type of value they operate on, where this makes
sense.
JerryScript-DCO-1.0-Signed-off-by: Dániel Bátyai dbatyai@inf.u-szeged.hu
By using constructors/destructors we unify the case of static linking with
that of dynamic linking, and we reuse the build flag FEATURE_INIT_FINI. Using
constructors/destructors also allows us to cover the case where library
constructor/destructor functionality is unavailable, because we can expose the
module registration/unregistration functions as global symbols, to be called
explicitly from within the application.
Fixes https://github.com/jerryscript-project/jerryscript/issues/1952
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof gabriel.schulhof@intel.com
This extension provides the following facilities:
- registering modules,
- module resolvers, and
- an API for retrieving a module instance given its name.
A module is defined as a global static structure containing a pointer
to a string which is the name of the module, and a pointer to a function
which will be called when an instance of the module is needed.
A module resolver is a function that accepts a string holding the name
of the module and returns a `jerry_value_t` in an out-parameter and
`true` if the module was found, or `false` if it was not. If it returns
`true` and the out-parameter has the error flag set then the API will
pass it through without caching.
This extension provides a built-in module resolver which attempts to
load modules that follow the above module definition.
The API provided by this extension invokes all module resolvers it
receives in sequence to attempt to resolve the name of a single module.
After one resolver returns `true` and a `jerry_value_t` that represents
the module the API stops iterating over the remaining resolvers and
caches the value if its error flag is not set. It then returns the
`jerry_value_t`. The API will return a `jerry_value_t` containing an
error indicating that the module was not found if it reaches the end of
the list of resolvers. The error it returns has an extra property
`"moduleName"` the value of which is a string containing the name of the
module that the API was asked to resolve.
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof gabriel.schulhof@intel.com
