[webkit-reviews] review granted: [Bug 184041] [GLIB] Add JSCWeakValue to JavaScriptCore GLib API : [Attachment 336585] Patch

[bugzilla-daemon at webkit.org]

Michael Catanzaro <mcatanzaro at igalia.com> has granted Carlos Garcia Campos
<cgarcia at igalia.com>'s request for review:
Bug 184041: [GLIB] Add JSCWeakValue to JavaScriptCore GLib API
https://bugs.webkit.org/show_bug.cgi?id=184041

Attachment 336585: Patch

https://bugs.webkit.org/attachment.cgi?id=336585&action=review




--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 336585
  --> https://bugs.webkit.org/attachment.cgi?id=336585
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=336585&action=review

> Source/JavaScriptCore/API/glib/JSCWeakValue.cpp:193
> +	   g_signal_emit(weakValue, signals[CLEARED], 0, nullptr);

I'm hesitant about this signal. Wouldn't it be better for the user to pass in a
GWeakNotify to be called instead of using a signal? The signal makes it hard to
use in performance-sensitive code.

I even thought about suggesting that JSCWeakValue be a GBoxed or even an opaque
struct instead of a GObject, but I suppose since JSCValue is a GObject it's
better to parallel that.

> Source/JavaScriptCore/API/glib/JSCWeakValue.cpp:260
> +	       static_cast<GParamFlags>(WEBKIT_PARAM_WRITABLE |
G_PARAM_CONSTRUCT_ONLY)));

Might want to add a warning comment as to why it must never be made readable.

> Source/JavaScriptCore/API/glib/JSCWeakValue.cpp:299
> + * Returns: (transfer full): a new #JSCValue or %NULL if @weak_value was
cleared.

I was worried about the JSCValue being destroyed on the GC thread, but I
suppose that cannot ever happen because you take a lock here and return a
strong ref. That's the main thing I was looking to see in this review. Good.

> Source/JavaScriptCore/API/glib/JSCWeakValue.h:54
> +    void (*_jsc_reserved0) (void);

It has a signal, why not expose it here?