Add Object::set_native_object_data

[johnyob]

Related issue: #3314

This PR permits one to set the native object data of a Object using Object::set_native_object_data.

use boa_engine::{Context, object::ObjectInitializer};
let context = &mut Context::default();
let js_unit = ObjectInitializer::with_native((), context).build();

// Now stores 42 instead of unit
let _ = js_unit.borrow_mut().set_native_object_data(42u8);

[codecov]

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (07e2356) 44.59% compared to head (732da70) 44.58%.

Files	Patch %	Lines
boa_engine/src/object/mod.rs	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3480      +/-   ##
==========================================
- Coverage   44.59%   44.58%   -0.01%     
==========================================
  Files         487      487              
  Lines       50601    50605       +4     
==========================================
  Hits        22563    22563              
- Misses      28038    28042       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jedel1043]

I'm pretty sure this change conflicts with #3479.

In general, we ensure objects cannot change type after creation; this is to ensure APIs such as JsNativeObject cannot panic. However, this API in combination with #3479 would make it possible to do things such as:

let data = ();
let object = JsObject::from_proto_and_data(proto, ObjectData::native_object(data));
let wrapper: JsNativeObject<()> = JsNativeObject::from_object(object).unwrap() // cannot panic
wrapper.borrow_mut().set_native_object_data(42u8);
let unit = wrapper.as_mut() // PANIC!

[johnyob]

I'm aware of this 😔

Unfortunately I'm not too sure what the best approach is. For some context, we'd like this to permit passing a unsafe JsNativeObject<T> for a constructor of T which would then use set_native_object_data to make it safe again.

[jedel1043]

For some context, we'd like this to permit passing a unsafe JsNativeObject<T> for a constructor of T which would then use set_native_object_data to make it safe again.

Must you specifically use JsNativeObject<T>? Or can you use Class APIs? I was thinking that the JsNativeObject::new should be integrated in Class instead, so that it returns a JsNativeObject after calling construct. Would that solve your specific case?

Otherwise, do you have a link to your use case? I'll try to think on an API that solves it without having to change the type of an object.

[johnyob]

Must you specifically use JsNativeObject? Or can you use Class APIs? I was thinking that the JsNativeObject::new should be integrated in Class instead, so that it returns a JsNativeObject after calling construct. Would that solve your specific case?

Yes. So for some more context, we have our own Class API (called NativeClass) which can be found here.

Integrating the creation of a JsNativeObject more closely with class would be suitable for our use case.
Specifically we want to support constructors such as Url::new which relies a native object reference JsNativeObject<Url> to pass to the UrlSearchParams object to permit the cyclic link between URL and URLSearchParams from the URL spec.

[jedel1043]

Nice! In that case, we can close this and plan the integration of JsNativeObject with the Class trait.