After comments on the previous attempt (which I will update to fix all those issues later this week), the issue of ->extra and its continued usage in resource modules came up. Here are some possible solutions.
$info->jswindow (WINDOW_SAME**, WINDOW_NEW, WINDOW_POPUP)
$info->jswidth, ->jsheight (used only if WINDOW_POPUP; if not specified default to 620, 450)
This is simpler, basically we can just replace the 'extra' which I don't like because it seems a bit hacky, with a specific function:
$info->onclick (text of onclick)
Leave the system as it is but un-deprecate extra (& add it to the 'class' version).
Not related to the above and could definitely be left for later if that's sensible. But just something else I noticed.
If adding fields, may also be good time to check that modinfo is 'minimised' in db e.g when saving to database, we only include in the serialised object any fields which have non-default value (like if grouping is 0 we don't save it, if extra is '' we don't save it, that kind of thing) and reconstruct using empty() ? : type syntax when constructing in memory, as done for some fields already.
Our typical (median) modinfo is about 22KB. That's quite long for one field. I think it can probably be reduced by a significant proportion (maybe even 50%+) if we just don't store unused fields. Not sure that transferring 20KB from database each time we get a course record really causes a problem, though, so this might not particularly be a big performance win, just seems sensible.
22KB is typical (median), but just for amusement, here is the OU live system top 10 modinfo length (characters):
1156226 (woo, we broke the 1MB barrier!)
these are in our 1.9 (+ OU bits, some of which do add to modinfo) but I don't think the code is much different in 2... the #1 course there has 1449 course modules (incidentally most of these are labels), while #10 has only 213... I don't have convenient test code to create a course with 1000 activities in moodle 2 but I suspect the result would be similar.