runtime: introduce LuteLibrary shared interface for runtime modules.#959
Open
runtime: introduce LuteLibrary shared interface for runtime modules.#959
LuteLibrary shared interface for runtime modules.#959Conversation
Vighnesh-V
reviewed
Apr 9, 2026
Comment on lines
+45
to
+51
| static int openAsGlobal(lua_State* L) | ||
| { | ||
| verifyInterface(); | ||
| Derived::pushLibrary(L); | ||
| lua_setglobal(L, Derived::kName); | ||
| return 1; | ||
| } |
Collaborator
There was a problem hiding this comment.
I have a small q - this function uses ::pushLibrary and ::kName so it makes sense to assert for them. Does it still make sense to assert for lib and properties, since these can just be implementation details wherever they are needed, and the derived classes don't have to use properties if they aren't exported?
Vighnesh-V
reviewed
Apr 9, 2026
| static int openAsGlobal(lua_State* L) | ||
| { | ||
| verifyInterface(); | ||
| Derived::pushLibrary(L); |
Collaborator
There was a problem hiding this comment.
Do you think it's possible for this to exist as an implementation on the LuteLibrary? I'm looking at the existing pushLibraries we have and it looks like they're all doing pretty much the same thing? I guess metatable initialization is the main difference here right?
Vighnesh-V
reviewed
Apr 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There's a lot of inconsistency between the different runtime library definitions, and it's bothered me for a while. To try to make things more structured, this PR introduces a shared interface
LuteLibraryand refactors each library namespace to instead be astructthat implements thatLuteLibraryinterface. The goal here is to make it more difficult to author a library that isn't structured how we would expect, and to bring all of the existing libraries into that uniform structure.I'm not necessarily 100% convinced that this is worth it, but I think it came together well enough that I want to solicit other opinions on it. Does this look and feel better to work on going forward? It definitely looks to make headers, especially, a lot more uniform. The static_asserts in particular are a bit janky, but it seems arguably nicer than the alternative of doing an abstract class with all of these fields virtual.