Use 'on' instead of 'connect' for signals

[benwaffle]

No description provided.

[magcius]

Signals work differently from that in node, and the differences are subtle enough that I don't want to confuse the two. Closing for now, but I would be OK with accepting one of those transformation modules I listed. You would expose the base class somewhere private inside JS, and then do GIBaseClass.prototype.on = GIBaseClass.prototype.connect;

[benwaffle]

Signals work differently from that in node

What are the differences

[magcius]

To start, the API is different. In node, the on method returns the emitter, so you can chain. In my GObject implementation, it returns the signal ID, which you then pass to disconnect (or could if I implemented that). In node, to disconnect a signal, you call removeListener with an event / listener pair.

In GObject, signals can return values for more complex accumulation behaviors. node signals don't have accumulation behaviors.

GObject signals have more complicated interactions with vfuncs. For instance, there's g_signal_connect and g_signal_connect_after.

You can block signals with g_signal_handler_block. Signal propagation is actually really complicated, and node's events API doesn't have all the functionalty of GObject.

In GObject, the value of this is undefined and the object that emitted the signal is the first argument. In node, this is the emitter object, and the arguments are always the user-submitted arguments.

Again, if someone wanted to map these differences, I would be OK with a module that implemented node-like semantics on top of lower level primitives. But I don't want to simply rename, call it a day, and get the community really confused.

[WebReflection]

FWIW I 100% agree with @magcius here. Worth exploring a normalizer for the GObject prototype in a module a part.