@leeoniya

I am opening this as a new issue because I want others to be able to find it easily, and I don't want to confuse the issue with the recent enhancements to event handling (#235). So this should be food for thought (I would have opened a discussion item, if discussions were enabled). I should note up front that I don't really have a big dog in this fight, since I don't usethis and with recent changes I can now live with simplyalways using parameterized handlers.

There remain four ways in which DOMVM parameterized event handlers (henceforth p-handlers) are inconsistent with JavaScript event handlers (henceforth e-handlers):

1. Thethis for e-handlers is the current target; for p-handlers it's the current vm.
2. The first argument for e-handlers is the event; for p-handlers the event argument is after whatever arguments were attached in the handler declaration.
3. The only argument for e-handlers is the event; for p-handlers DOMVM implicitly adds node, vm, and vm.data.
4. Theonevent handlers are not called for e-handlers, and they are for p-handlers.

My issue with these differences is that none are technically necessary, and the differences create additional cognitive load and code fragility for me. Given that there's no longer a performance penalty for one or the other, I feel the differences are no longer technically justified. Note that I am not intending to speak to compatibility concerns -- that alone might render the entire discussion moot.

When I am deciding between an e-handler and a p-handler theonly factor in view is whether or not I need to bind context arguments. Often, as the design shifts, and especially when I am first developing a component, a specific handler will change from normal to parameterized, or vice versa. Doing so makes the existing handler code broken in subtle ways, and it's easy to forget one of them, which becomes a runtime error, often a fatal one, that occurs only when that event handler is actually triggered. Painful to test and easy to miss.

The cognitive load increase is related, but applies to every handler I write -- is it an e-handler or p-handler; does it have arguments ofevt,vm,nod,dta or justevt. Will theonevent handler be called or not (if I am using an auto-redraw system this could be critical). For programmers accustomed tothis, I imagine havingthis be the current target in one context and the vm in another would be a constant source of frustration.

As reflected in my recent pull request these issues could now be easily addressed, and though doing so would break compatibility a case could be mounted that these are bugs.

The changes would be:

1. Bindthis tocurrentTarget.
2. Always use theexec function.
3. Bind added arguments after the event, so instead of(...,evt,node,vm,data) useevt,...,node,vm,data).

The argument for#1 is purely consistency with JavaScript in general. Thethis value is always current-target, for every event handler I see in every JavaScript context.

The argument for#2 is that the extra arguments do no harm and consistencywithin DOMVM code is better than inconsistency. This is the one that is the least important; there seems to be some defense for only adding the DOMVM arguments to p-handlers, so I lean toward doing this, but not strongly.

The argument for#3 is that the event is the "fundamental" JavaScript argument, the explicitly declared arguments are context-specific, and node, vm, and data are implicit DOMVM "value-added" arguments. The event argument is always there, and it's always first, for every event handler I see in every JavaScript context -- the precedent for this is overwhelming. Theexplicit added arguments specified in the declaration seem to be naturally expected next, then finally theimplicit DOMVM arguments.

As I said, food for thought; and in my opinion worth a major version bump and a breaking change to remove this constant source of friction.