Posted by sand1024 on Jan 31, 2025; 5:59pm
URL: https://forum.librecad.org/Incorrect-pen-results-from-the-entitycontainer-tp5726283p5726285.html

BTW, answering on your question I've took a really quick look on the surrounding code.

Actually, I'm not sure that the general approach you'd like to use is correct.  

For sure, it's clear that the code LibreCAD/librecad/src/lib/scripting/lisp/Core.cpp attempts to provide a set of API that will be invoked from the scripts.

However, I think that the current implementation could be improved, by separation of the API logic itself and language-specific scripting boilerplate code. At the moment, the code there is tightly coupled, as for me.

Separation of concerns (api / scripting ) brings several important benefits:

1) API may be be reused, both by core logic and scripting
2) It may be reused by various languages (lisp/python/etc)
3) Scripting subsystem is better isolated from changes in underlying core logic - but relying on API interface instead of internal details.
4) Lot's of internal complexity of the major core is hidden from scripting.
5) Booth classes for scripting and api logic are more compact and maintainable.

Basically, the idea behind above is quite straightforward. For example (just as illustration), the method

BUILTIN("vl-file-rename")

could be implemented as something like this:

BUILTIN("vl-file-rename")
{
    CHECK_ARGS_IS(2);
    ARG(lclString, path);
    ARG(lclString, newName);

    book ok = m_scriptingAPI->renameFile(path, newName);
    return ok ? lcl::trueValue() : lcl::nilValue();
}

Where all actual logic of checking file existence and renaming is implemented in method of another class, and m_scriptingAPI is just a reference to such class.

The same approach is applicable for other functions.

Please consider such decomposition.

If you need some additional support with exposing some core logic to scripting or adding some functions that may be used in scripting - please let me know.