I'm implementing the null provider for one of my plugin: it turns out that the Privacy API is not the same across the Moodle versions, as done for the other Moodle APIs since it depends on the branch precisely on the PHP version applicable on that branch.
Shortly, Privacy API differs in 3.3 from 3.4 since it "misses" the return type declaration e.g in the null provider: such a difference will require two different branches on my plugin (3.3 and 3.4+) since maintaining the same plugin code for the two version cannot be supported due to the "damn" return type declaration.
Is it actually the first time a Moodle API is "inconsistent" between the versions supported by it?
Example, 3.3 vs 3.4 (PHP 5.6 vs 7.0+): https://github.com/moodle/moodle/commit/267e1af112542db53d9587c7bed2aa6c2ef5a287#diff-76c75e389f2a5886c310feb7ce46ed22R39 vs https://github.com/moodle/moodle/commit/289fe1ef760a72f481c423a91aba91f59abd541c#diff-76c75e389f2a5886c310feb7ce46ed22R39 .
while struggling with some other issues about plugin development and environment checks, Adrian Greeve has just updated the Privacy API docs to highlight that a polyfill is already there, to keep the same plugin branch for multiple Moodle versions support: https://docs.moodle.org/dev/Privacy_API#Difference_between_Moodle_3.3_and_more_recent_versions.
I'll try if it will work (why should I doubt about it? Late night yesterday on Moodle coding )
TNX Adrian for the sensitive docs update .
I suppose this is good news (Adrian's polyfill) but its really a bit of a drag that we have to go to polyfill isn't it?
For core code that will always be in sync its probably ok, but for an API that third party plugins need to implement it just ups the complexity ...kind of needlessly in my opinion. Do we really need to declare return types on eg, the privacy API get_metadata function?
yes, it is actually a good news which was unfortunately not publicly available at the time of my coding attempt: it could impact the development of those plugins that today live fine with a single branch policy release.
No, you don't need to declare the return type if you prepend each method with "_" and follow the documentation: see also an example - I'll tune it before 3.5 release e.g. checking the existence of the polyfill and not of the null_provider... - in https://github.com/scara/moodle-local_twittercard/blob/6e2d3ef971461d4eec041cef4cb459d658140087/classes/privacy/provider.php#L43 .
I could only imagine the "competition about software architecture" inside HQ on designing the Privacy API vs the need of backporting it at least on 3.3(.5): at the end what they call "the legacy polyfill" makes sense and leads to have the best of both worlds - best API design in newer Moodle releases and keep on playing with plugins using single branch policy release - , without missing a "modern" software design thanks to PHP 7.0+ (2+ yrs old) for the future releases (3.4.2+).
The only thing I could say is that being the first time of a different API design across (2) branches, much noise about the polyfill should have been done to avoid (my) initial ranting/complaining .