Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major overhaul #2

Open
wants to merge 35 commits into
base: master
Choose a base branch
from
Open

Major overhaul #2

wants to merge 35 commits into from

Conversation

apfeltee
Copy link

I was really impressed with this implementation, so over a coule days, I expanded my fork quite considerably.

Among things in regard to code style:

  • switched code directly to C++20. this will compile fine with recent mainline versions of GCC, clang, and VS.

  • split the code up. Yes, a single header sounds great on paper, but makes management difficult. The main API is still just one header (msl.h), and priv.h just contains code used in the core.
    So, once built, you'd still only need, say msl.h and libmsl.a.

  • got rid of PascalCase - you noted a problem with potential clashes with windows headers. switchinging to javaCase fixes this "problem" rather elegantly.

  • put enums inside classes where they matter, thus reducing namespace clutter

  • made some hard-coded values mildly more dynamic, such as the methods/properties of global core objects (strings, arrays, etc). these are still declared in stmt.cpp, but it's easier to expand now.

  • also removed the SystemFunction enum stuff, and instead implemented them properly with std::function values. Again, this makes expanding way easier.

  • there are many more, but these the most important.

As for the core:

  • expanded the core functionality quite a bit, with the core functions being created in env.cpp, and most of the code used in the stdlib residing in the *mod.cpp files (things like string formatting, Array.pop(), etc)

A few things still need addressing, such as performance:

  • Numbers are stored as double, regardless of what they're used for. This is very probably a major culprit in regards to performance.

  • Objects might be copied too much, but this could be tricky to determine

The core is now implemented in a way I find presentable, it does not leak any memory, there are no memory access issues, should compile cleanly with -Wall -Wextra, and is in effect now platform-independent.

Anyway, I'd love to know what you think, and if you think this is a good road to continue on.

John Doe added 30 commits January 10, 2022 04:25
… it's still just one header, but easier to maintain now
…h is needed for stuff like Array.map, Array.each, etc. callbacks in general
John Doe added 5 commits January 17, 2022 14:00
…ing point, Number can either store a floatingpoint number, or integer, with corresponding ops abstracted to fit it. may seem verbose, but *not* using floatingpoint for everything increases performance considerably
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant