Implement `WeakReference`, `Finalizer` in dartdevc

[mraleph]

[devoncarew]

@sigmundch - who's a likely owner here?

[dcharkes]

@lrhn suggested that if detach is omitted in Finalizer.attach we use value as the detach object.

I'll update the documentation in the VM CL, but of course it should be implemented as such in dartdevc as well then.

https://dart-review.googlesource.com/c/sdk/+/229544/8/sdk/lib/core/weak.dart#185

[rileyporter]

Sounds good, will do!

[mraleph]

@dcharkes @lrhn I don't think we should do this. I would actually expect most finalizers to not be detachable so it does not make sense to introduce this book keeping overhead by default.

[lrhn]

Unnecessary overhead was my main worry.
From a usability point of view, I think it's actually a good idea to make objects default to being detachable by themselves. The few pieces of code I wrote, just to test the API, made me want to pass the object itself as detach-object, but you can always do that explicitly. It's just much easier not to have to.

The current implementation uses a Dart-side weak-map to map detach objects to "attachment ID"s. Would you still worry about overhead if that mapping we kept in the native implementation instead, as part of the same data structure which maintain the attachments. (Or is the lookup requirement going to make it equally expensive in native code?)

[mraleph]

@lrhn I think I would still be worried. I would like most common use-case to be very low-overhead --- meaning that there should be no additional book-keeping allocated beyond absolutely necessary one e.g. in case of NativeFinalizer you only really need a weak handle and a small piece of peer data associated with the handle. No weak-maps are involved here.

Maybe for Finalizer my concern does not apply, I need to think what is the most optimal representation there. But I would imagine that JS folks did not make it default because they had similar concerns - it is highly likely that associating detachment key costs significantly on the Web.

[mraleph]

I just want to check if we are in agreement that we are not going to change API and keep the original (JS) semantics where you need to explicitly pass detach: object if you want to make the finalizer detachable.

[dcharkes]

I have updated the CL to not use value as default detach anymore.

[rileyporter]

DDC implementation landed in 278a040