-
-
Notifications
You must be signed in to change notification settings - Fork 407
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
Js typed array methods #3481
Js typed array methods #3481
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice work! Just have some suggestions.
bdfaab0
to
66b6a6d
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3481 +/- ##
==========================================
- Coverage 47.24% 47.01% -0.24%
==========================================
Files 476 477 +1
Lines 46892 47494 +602
==========================================
+ Hits 22154 22327 +173
- Misses 24738 25167 +429 ☔ View full report in Codecov by Sentry. |
This comment was marked as resolved.
This comment was marked as resolved.
61106e1
to
f1c29d2
Compare
Should probably be renamed to |
270dded
to
5a28e12
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Don't worry about that. We haven't implemented the |
265202a
to
c291beb
Compare
I want to summarize the current status of the PR: function implemented:
function implemented but:
i don't know how to implement it
iterators are unstable
desired features
@jedel1043 in your opinion what can be the next steps? Can we review each implementation to align with the desired feature and reduce the utilization of |
Yep, it'll be good to check already implemented functions to see if we can improve the API on them, but that can be done in another PR.
Probably to check the JS implementation to see if there are any patterns on the return types of the methods; methods returning only |
Also, when you feel like this is ready, just ping me so that I can change the label to |
hi @jedel1043 pub fn buffer(&self, context: &mut Context) -> JsResult<JsValue>
pub fn constructor(&self, context: &mut Context) -> JsResult<JsValue>
pub fn copy_within<T>( &self, target: T, start: u64, end: Option<u64>, context: &mut Context,) -> JsResult<Self> where T: Into<JsValue>
pub fn find_index( &self, predicate: JsFunction, this_arg: Option<JsValue>, context: &mut Context,) -> JsResult<Option<u64>>
pub fn find_last( &self, predicate: JsFunction, this_arg: Option<JsValue>, context: &mut Context,) -> JsResult<JsValue>
pub fn find_last_index( &self, predicate: JsFunction, this_arg: Option<JsValue>, context: &mut Context,) -> JsResult<Option<u64>>
pub fn foreach( &self, callback: JsFunction, this_arg: Option<JsValue>, context: &mut Context,) -> JsResult<JsValue>
pub fn includes<T>( &self, search_element: T, from_index: Option<u64>, context: &mut Context,) -> JsResult<bool> where T: Into<JsValue>
pub fn set_values( &self, source: JsValue, offset: Option<u64>, context: &mut Context,) -> JsResult<JsValue>
pub fn subarray(&self, begin: i64, end: i64, context: &mut Context) -> JsResult<Self> from your point of view should any of these fn signs be improved, make the types more explicit? |
c291beb
to
a87e84f
Compare
hi @jedel1043, It's been a while. What are our next steps? Did I forget to complete something specific? Can I assist with any tasks for the review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great overall! Really nice job!
I had just a couple nits.
|
||
/// Calls `TypedArray.prototype.forEach()`. | ||
#[inline] | ||
pub fn foreach( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Should this be in snake case?
This is extending the API from BuiltinTypedArray
, but we use for_each
in other places in the engine. Would it be better to maintain consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @nekevss, big thanks for your support! Apologies for the delay; I got tied up with something else. Now, I'm eager to maintain continuity with this.
I used foreach
because the internal API BuiltinTypedArray::foreach
uses it too. But I'm flexible to rename it for consistency with the right naming conventions also in the internal api, following your guidance.
If you approve, I'll proceed to rename both. Otherwise, do we prefer to keep the internal API unchanged? give me feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jedel1043 any thoughts on the use of snake case with foreach
on the internal API for BuiltinTypedArray
.
In general, I'm of the opinion for at least the external API to be closer to the Rust convention. Anyone who consumes the API will probably expect snake case. At minimum, we should probably be at least consistent throughout the engine on whether it's foreach
or for_each
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we mostly agree on always converting camelCase JS APIs to snake_case Rust APIs. IMO, functions that differ from this convention should be treated as naming bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good! 😄 Then let's go with renaming the functions from foreach
to for_each
for naming.
@@ -273,6 +358,104 @@ impl JsTypedArray { | |||
) | |||
} | |||
|
|||
/// Calls `TypedArray.prototype.findIndex()`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would be more meaningful to enhance the builtins/jstypedarray.rs module with standard Rust documentation, or should we focus solely on improving the code in the examples folder? I drew a lot of inspiration from MDN for those examples, because originally I hadn't thought about it; I used them as acceptance tests to ensure the implementation was correct. However, I'm open to reconsidering them as documentation if that would be more beneficial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rule of thumb is to have examples that demonstrate HOW to use the APIs as doc comments, and to have examples that demonstrate WHEN to use the APIs as code examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The module level rustdoc
documentation was more what I meant in this instance. The examples don't have to be a completely different from those in examples
. Mostly since the Rust documentation will be auto generated into the docs, which is super handy and may be the first place someone consuming the API would go for information. For example, here's the JsPromise
docs for reference
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really nice! I think it's a good call to adapt the examples from MDN, since it removes the effort of having to come up with descriptive usages.
As a small suggestion, I would remove the "The FindIndex method of Array instances" prefix, since it is mostly idiomatic to start a method's documentation with a verb; in this case, "Returns the index of...".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added doc tests to all the functions I've touched. Give me feedback!
703411b
to
c5e0b76
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great! I have a one nit about the docs, but nothing else really.
f0f816e
to
81cdd22
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for contributing to Boa! 😄
EDIT: Looks like this needs a cargo fmt -all
81cdd22
to
a9cc900
Compare
Done! And sure... please close this PR. However, if we want to discuss the points further: i don't know how to implement it
iterators are unstable
desired features
I'm open to contribute. I'm also open to adding(the remaining) Rust test documentation to the jstypedarray module in another pull request. What do you think? |
I think it's fine to only expose this in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice work! It's also really helpful to have so many new doc tests for this wrapper. There are definitely some other optimizations that can be done, but having the methods in place is already a big improvement.
This Pull Request pertains to issue #3252
It implements the following JsTypedArray methods:
Hi guys!
I'd like to create this draft pull request to share my work on the issue through examples and seek feedback. Is that alright with you? I'll gradually compile this post as I make progress on the issue.