Mark Johnson (talk | contribs) (Added description of proposed namepspacing convention) |
Mark Johnson (talk | contribs) |
||
| Line 3: | Line 3: | ||
'''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 | '''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==== | ====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. | 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 <tt>{plugintype}_{pluginname}_</tt>, 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() | 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 <tt>report_targetgrades_print_tabs()</tt> since there is already a global function called <tt>print_tabs()</tt>. The majority of this name is only there to avoid name collisions, and it otherwise redundant. | ||
====Proposal==== | ====Proposal==== | ||
Revision as of 08:49, 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() since there is already a global function called 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.
