Developer Area/Developer Meetings/52

Agenda for the 52nd Mahara developer meeting on Thursday, 28 April 2016, 7:00 UTC

The developer meetings are held on IRC in the #mahara-dev channel. An IRC bot will be used to take minutes of these meetings and agendas made available on these pages before-hand.

If you don't have an IRC client, you can join us using your web browser.

Chair: Kristina

Agenda:

1. Topics from previous meeting
   1. mingard will work on finding and documenting duplicated sections, and maybe do a bit of a proposal on how we should restructure the scripts generally
   2. anzeljg will try to create some plans/wireframes for simplifying Mahara create page procedure
2. Your topic goes here
   1. Drop support for PHP 5.3? --aaronw (talk) 18:42, 29 March 2016 (NZDT)
      1. Latest version of PEAR, a Mahara dependency, now requires PHP 5.4 or later. Perhaps it's time Mahara should raise its supported PHP version to 5.4 as well.
      2. We previously discussed this topic 1 year ago, Dev Meeting 43, in April 2015. The decision then was to gather more data about which PHP versions are in use by expanding the site data registration.
      3. The latest stats (from Dev Meeting 50 in Feb 2016) still had 20% on PHP 5.3. I'll try to gather more stats before the next meeting.
   2. Switch to PSR-2 coding standard? --aaronw (talk) 16:21, 1 April 2016 (NZDT)
      1. http://www.php-fig.org/psr/psr-2/
      2. Should be easier to find auto-formatting tools; less barrier for devs new to the project
   3. Namespaces & autoloading? --aaronw (talk) 16:21, 1 April 2016 (NZDT)
      1. Currently Mahara has a lot of standalone methods, and after a recent performance patch that removed an unnecessary loading of *every* artefact class on *every* page load, we now have a "dependency hell" situation where some random actions will fail because they expect a function to be present (usually artefact_get_descendants()) but no scripts have yet loaded it.
      2. We could avoid that problem if we did this:
         1. Move all standalone methods into static class methods (perhaps one class per library file)
         2. Put Proper PHP namespaces on all of our library files (namespace supported was added in PHP 5.3)
         3. Add an autoloader method that loads up the correct Library file based on the class name and namespace: http://php.net/manual/en/language.oop5.autoload.php
      3. This will have the added benefit of "modernizing" our code and getting it more compatible with the modern PHP code ecosystem.
      4. Downside: all code that calls standalone Mahara functions will need to be fixed to include the classname for each function.
         1. We can write automated tools to fix most instances of this (although I would not be surprised to discover there are cases where the function name is determined dynamically).
         2. For backwards-compatibility with 3rd-party plugins, could make a "compatibility" module that declares a standalone method matching each of the current ones in Mahara and simply passing through the call to the new static one. e.g.: function artefact_get_descendants($ids) { return \Mahara\Artefact\ArtefactUtil::artefact_get_descendants($ids); }
3. Next meeting and chair
4. Any other business