Mark Johnson (talk | contribs) (Initial outline of plan) |
Mark Johnson (talk | contribs) (Added description of proposed namepspacing convention) |
||
Line 9: | Line 9: | ||
====Proposal==== | ====Proposal==== | ||
I am going to upgrade one of my Moodle 1.9 blocks for use in Moodle 2.x. During this process I will alter the libraries to use namespaces, allowing functions, classes and constants to have shorter names while still avoiding name collisions. In files including these libraries, I will use namespace aliases to allow the functions/classes/constants to be called using much shorter notation. | I am going to upgrade one of my Moodle 1.9 blocks for use in Moodle 2.x. During this process I will alter the libraries to use namespaces, allowing functions, classes and constants to have shorter names while still avoiding name collisions. In files including these libraries, I will use namespace aliases to allow the functions/classes/constants to be called using much shorter notation. | ||
=====Naming convention===== | |||
As mentioned above, the current naming convention for prefixing functions is <tt>plugintype_pluginname</tt>. It makes logical sense to use a similar convention in the namespace hierachy - each plugin having a namespace of <tt>plugintype\pluginame</tt>. For example, all admin reports would have their functions the <tt>report</tt> namespace, and the Target Grades report described above would have it's own sub-namespace, <tt>report\targetgrades</tt>. |
Revision as of 08:48, 24 May 2011
Notes about using PHP namespaces in Moodle plugin development
Goal: To take advantage of namespace features in PHP 5.3 to allow plugins to be written with less verbose function names, while still avoiding name collisions
Current Issue
When writing a plugin, one creates a lib.php or locallib.php containing a set of functions for use within that plugin. Each function name (and similarly, constant names and class names) must currently be prefixed in the format {plugintype}_{pluginname}_, to avoid a function that performs a similar task in a separate plugin having the same name, thus causing a name collision.
This can result in overly verbose function names which inhibits both readability and ease of writing of code. For example, a function for printing tabs in an admin report named targetgrades would need to be called report_targetgrades_print_tabs() - the majority of this name is only there to avoid name collisions, and it otherwise redundant.
Proposal
I am going to upgrade one of my Moodle 1.9 blocks for use in Moodle 2.x. During this process I will alter the libraries to use namespaces, allowing functions, classes and constants to have shorter names while still avoiding name collisions. In files including these libraries, I will use namespace aliases to allow the functions/classes/constants to be called using much shorter notation.
Naming convention
As mentioned above, the current naming convention for prefixing functions is plugintype_pluginname. It makes logical sense to use a similar convention in the namespace hierachy - each plugin having a namespace of plugintype\pluginame. For example, all admin reports would have their functions the report namespace, and the Target Grades report described above would have it's own sub-namespace, report\targetgrades.