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

Jump to: navigation, search
(Current Issue)
m (Made headers higher level)
Line 1: Line 1:
===Notes about using PHP namespaces in Moodle plugin development===
+
==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
 
'''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 <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.   
 
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 <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.
 
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===
 
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=====
+
====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>.
 
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:50, 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.