But ON SOCKOPEN is not. Neither is ON SOCKWRITE. They don't trigger randomly, they trigger in response to typing /sockopen or /sockwrite respectively.
apparently you misunderstood me, or we're thinking about this in different ways. on SOCKOPEN and on SOCKWRITE only follow their respective /sock* commands (i said this originally). you said this:
Actually, by your reasoning, /sockopen should not trigger ON SOCKOPEN. Similarly, /sockwrite should not trigger ON SOCKWRITE.
that's wrong. on SOCKCLOSE doesn't follow /sockclose because there is an external stimulus involved. this external stimulus does not come in to play with on SOCKWRITE or on SOCKOPEN, that's why it's not sensible to compare them to on SOCKCLOSE.
Sorry, no, I don't acknowledge this as more common.
you missed the point i'm afraid. i realize that specific method is uncommon (it's the only example i had, commented out, in my scripts), that's why i qualified it with 'similar to'. what we would typically see is more like:
on ^*:open:?:*:{
if (!%qnick) {
.msg $nick Please await query authorization...
echo -ea $nick just queried you with: $1-. Press F2 to accept or F3 to reject.
%qnick = $nick
halt
}
}
alias f2 query %qnick I have accepted your query request. | unset %qnick
alias f3 .msg %qnick I have denied your query request | unset %qnick
not great, but typical. i'm not saying the fixes would be complicated, but why do you want to introduce a problem? we've already witnessed the effects on the public of abrupt changes to the client, namely: discontinuation of code page support.
the way i see it, it's as simple as: if you change on OPEN then some people will be impacted negatively, if you add an event prefix then they will not. you said it yourself:
There is no backwards compatibility issue with added behaviour.
what you're proposing is a change, what i'm proposing is added behaviour.
