The more standard "mediawiki way" is usually to build up the list, and then insert a hook after the building, but before the action, to allow extensions to add/remove from the array

software wrote:

I can contribute to one or more patches that:

1. First build a list of recipients before sending them all (curently, the compose() function is called at multiple places.)
2. Add a hook function with (a pointer to) the recipient list, so extension can modify the list.
3. Modify the parameters in the existing function so the hook can include a pointer to the recentchange flags, or even to the recentchange instance.

Does this sound reasonable?

What should the hook function look like?

'ActionModifyEnotifRecipients': before sending email notifications about page
changes or creations; allows change the list of recipients.
&$recipients: list of recipients
$editor: User object
$title: Title object
$timestamp: string representing timestamp of the edit
$summary: string summary of the edit, provided by the editor
$rc: RecentChange object

This proposal only allows modifications to the recipient list. It does not allow modifications of the mail body, subject, etc. Would it be useful to include those parameters as well, or would those be subject of another hook?

actuallyNotifyOnPageChange() currently only knows about oldid (to distinguish between page change and page create) and minorEdit. It seems to me that the parameters bot, patrolled, old_len and new_len (to check if it really is such a minor edit) and perhaps others are relevant as well to judge if an email alert is warranted or not. To make it flexible, I propose to include a pointer to the RecentChange object, even it requires a modification of the parameters of actuallyNotifyOnPageChange().

A last issue is that the above proposal places the extension hook in EmailNotification class. It is also possible to put the hook in the RecentChange class. In fact the aforementioned r44960 added line 217 to RecentChange.php, just when calling EmailNotification:

1. @todo FIXME: This would be better as an extension hook

Once we agree on the location and syntax of the hook, I can write a patch.

Created attachment 9815
the mediawiki way?

I think the attached diff would be more in line with Reedy's proposal. It'd be nice if RecentChanges handled Status objects, too.

Attached:

You are returning a Status object, but notifyOnPageChange() doesn't return anything (so the user-mail-enotif-list message is also unneeded).
Also, I think you are passing too few parameters. You would want at least $watchers there, which could be modified to add/remove addresses (eg. you could have an extension which mailed a different team depending on the day of the week), something like the parameters of actuallyNotifyOnPageChange.
Probably placed above "if ( $watchers ) {", but moving it outside its outer if.