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

auto-publishing of C symbols and types #29

Open
capr opened this issue Oct 27, 2015 · 0 comments
Open

auto-publishing of C symbols and types #29

capr opened this issue Oct 27, 2015 · 0 comments

Comments

@capr
Copy link
Member

capr commented Oct 27, 2015

Something I should have done a long time ago: add an __index to the winapi namespace table that will dynamically look up and publish (i.e. add to the namespace table) symbols from various sub-namespaces:

  • winapi.TYPE -> winapi.types.TYPE <- non-array ctype constructor
  • winapi.ARRAY -> winapi.arrays.ARRAY <- array ctype constructor
  • winapi.SYM -> winapi.C.SYM <- C function, enum or constant

Currently publishing of unwrapped types and functions is done manually, i.e. FooFunc = C.FooFunc or FooType = types.FooType and so on. The idea is to make this publishing happen automatically on first access. After this change, we can remove all these lines in the code.

The idea is explained nicely by William Adams: https://williamaadams.wordpress.com/2015/10/26/

PS: I am also wondering if there's any benefit to moving constants from the winapi namespace (which is a Lua table) to C enums which are also stored in a Lua table internally, except I heard that access to them is compiled.

PS2: TBH I don't think many people use the low level APIs that much and when they do, they probably wrap them, not use them directly, and it's arguably more readable to see explicit references to these sub-namespaces in the code instead of magic lookups. That being said, anything that helps us remove repetitive tedious code in winapi is a good deal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant