Difference between revisions of "User:Mark Johnson/Namespaces"

Jump to: navigation, search
(Initial outline of plan)
 
(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.