mirror of https://github.com/boa-dev/boa.git
Tree:
95a81984a0
add-vhs-ci
benchmarks
control-flow-graph
expect-lints
feature/node_span
feature/snapshot
features
gh-readonly-queue/main/pr-2877-b0ddf5eed00a53281d67fc7d846233fc0d99ce9c
gh-readonly-queue/main/pr-3144-8e48cec73fae708420b9af88813d4870243c491a
main
nan-boxing
optimization/static-shapes
real_conformance
reduce-environment-allocations
refactor/interner
refactor/register-vm
releases/0.17
releases/0.19
semver_checks
tco
utility-crate
wasm-debugger
nightly
v0.10
v0.11
v0.12
v0.13
v0.14
v0.15
v0.16
v0.17
v0.17.1
v0.17.2
v0.17.3
v0.18
v0.19
v0.19.1
v0.2.0
v0.2.1
v0.3.0
v0.4.0
v0.5.0
v0.5.1
v0.6.0
v0.7.0
v0.8.0
v0.9.0
${ noResults }
1 Commits (95a81984a01222180281cc89e47325db63f200c6)
Author | SHA1 | Message | Date |
---|---|---|---|
Iban Eguia Moraza | 540aa2be4f |
Initial version of a JS -> Rust conversion trait. (#2276)
This Pull Request closes #1975. It's still a work in progress, but tries to go in that direction. It changes the following: - Adds a new `TryFromJs` trait, that can be derived using a new `boa_derive` crate. - Adds a new `try_js_into()` function that, similarly to the standard library `TryInto` trait Things to think about: - Should the `boa_derive` crate be re-exported in `boa_engine` using a `derive` feature, similar to how it's done in `serde`? - The current implementation only converts perfectly valid values. So, if we try to convert a big integer into an `i8`, or any floating point number to an `f32`. So, you cannot derive `TryFromJs` for structures that contain an `f32` for example (you can still manually implement the trait, though, and decide in favour of a loss of precision). Should we also provide some traits for transparent loss of precision? - Currently, you cannot convert between types, so if the JS struct has an integer, you cannot cast it to a boolean, for example. Should we provide a `TryConvertJs` trait, for example to force conversions? - Currently we only have basic types and object conversions. Should add `Array` to `Vec` conversion, for example, right? Should we also add `TypedArray` conversions? What about `Map` and `Set`? Does this step over the fine grained APIs that we were creating? Note that this still requires a bunch of documentation, tests, and validation from the dev team and from the users that requested this feature. I'm particularly interested in @lastmjs's thoughts on this API. I already added an usage example in `boa_examples/src/bin/derive.rs`. Co-authored-by: jedel1043 <jedel0124@gmail.com> |
2 years ago |