|
|
|
|
[workspace]
|
|
|
|
|
members = [
|
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
|
|
|
"boa_ast",
|
|
|
|
|
"boa_cli",
|
|
|
|
|
"boa_engine",
|
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
|
|
|
"boa_examples",
|
|
|
|
|
"boa_gc",
|
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
|
|
|
"boa_icu_provider",
|
|
|
|
|
"boa_interner",
|
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
|
|
|
"boa_macros",
|
|
|
|
|
"boa_macros_tests",
|
|
|
|
|
"boa_parser",
|
|
|
|
|
"boa_profiler",
|
|
|
|
|
"boa_runtime",
|
|
|
|
|
"boa_tester",
|
|
|
|
|
"boa_unicode",
|
|
|
|
|
"boa_wasm",
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
[workspace.package]
|
|
|
|
|
edition = "2021"
|
|
|
|
|
version = "0.16.0"
|
|
|
|
|
rust-version = "1.66"
|
|
|
|
|
authors = ["boa-dev"]
|
|
|
|
|
repository = "https://github.com/boa-dev/boa"
|
|
|
|
|
license = "Unlicense/MIT"
|
|
|
|
|
description = "Boa is a Javascript lexer, parser and compiler written in Rust. Currently, it has support for some of the language."
|
|
|
|
|
|
|
|
|
|
[workspace.dependencies]
|
|
|
|
|
boa_ast = { version = "0.16.0", path = "boa_ast" }
|
|
|
|
|
boa_engine = { version = "0.16.0", path = "boa_engine" }
|
|
|
|
|
boa_gc = { version = "0.16.0", path = "boa_gc" }
|
|
|
|
|
boa_icu_provider = { version = "0.16.0", path = "boa_icu_provider" }
|
|
|
|
|
boa_interner = { version = "0.16.0", path = "boa_interner" }
|
|
|
|
|
boa_macros = { version = "0.16.0", path = "boa_macros" }
|
|
|
|
|
boa_parser = { version = "0.16.0", path = "boa_parser" }
|
|
|
|
|
boa_profiler = { version = "0.16.0", path = "boa_profiler" }
|
|
|
|
|
boa_runtime = { version = "0.16.0", path = "boa_runtime" }
|
|
|
|
|
boa_unicode = { version = "0.16.0", path = "boa_unicode" }
|
|
|
|
|
|
|
|
|
|
[workspace.metadata.workspaces]
|
|
|
|
|
allow_branch = "main"
|
|
|
|
|
|
|
|
|
|
# The ci profile, designed to reduce size of target directory
|
|
|
|
|
[profile.ci]
|
|
|
|
|
inherits = "dev"
|
|
|
|
|
debug = false
|
|
|
|
|
incremental = false
|
|
|
|
|
|
|
|
|
|
# The release profile, used for `cargo build --release`.
|
|
|
|
|
[profile.release]
|
|
|
|
|
# Enables "fat" LTO, for faster release builds
|
|
|
|
|
lto = "fat"
|
|
|
|
|
# Makes sure that all code is compiled together, for LTO
|
|
|
|
|
codegen-units = 1
|
|
|
|
|
|
|
|
|
|
# The test profile, used for `cargo test`.
|
|
|
|
|
[profile.test]
|
|
|
|
|
# Enables thin local LTO and some optimizations.
|
|
|
|
|
opt-level = 1
|
|
|
|
|
|
|
|
|
|
# The benchmark profile, used for `cargo bench`.
|
|
|
|
|
[profile.bench]
|
|
|
|
|
# Enables "fat" LTO, for faster benchmark builds
|
|
|
|
|
lto = "fat"
|
|
|
|
|
# Makes sure that all code is compiled together, for LTO
|
|
|
|
|
codegen-units = 1
|
