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

[feature] Intelligent selection of multiple implementations #15

Open
ToxicFrog opened this issue Mar 6, 2013 · 0 comments
Open

[feature] Intelligent selection of multiple implementations #15

ToxicFrog opened this issue Mar 6, 2013 · 0 comments
Assignees

Comments

@ToxicFrog
Copy link
Owner

vstruct uses a "safe, slow and stupid" approach to binary conversion that works in 5.1, 5.2, and luajit, and does not require binary loading, but is slow. It would be nice to have multiple implementations that it can combine at runtime, making use of 5.2's bit32 library and luaJIT's FFI when available, and possibly also having C implementations of some functions that it uses instead of the pure-lua versions if binary loading is available.

This would probably need multiple implementation directories (e.g. io/bin/, io/jit/, io/bit32/, and some kind of priority order; when it needs an IO handler it looks for the highest priority one that is actually available. This should be cached (I think this already happens, but maybe we're relying on require()'s cacheing, and this needs to be more intelligent than require()) so that don't go through the whole priority chain on every compile (or, worse, every IO operation). The pure-lua implementations are a fallback that's always available.

We may also want C/bit32 implementations of explode/implode, if there's a clean way to integrate them.

This also opens the door to supporting some IO formats that require these features, although I can't think of anything that would qualify offhand.

@ghost ghost assigned ToxicFrog Mar 6, 2013
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

No branches or pull requests

1 participant