Difference between revisions of "Automatic Class Loading Proposal"

Jump to: navigation, search
(Plugin class naming)
(Core class naming)
Line 42: Line 42:
  
 
The algorithm for finding of the class file location from class name is:
 
The algorithm for finding of the class file location from class name is:
# we have a class core_aaa_bbb_ccc_ddd
+
# we have a class ''core_aaa_bbb_ccc_ddd''
# look for file /lib/classes/aaa_bbb_ccc_ddd.php or /lib/classes/aaa/bbb_ccc_ddd.php
+
# look for file ''/lib/classes/aaa_bbb_ccc_ddd.php'' or ''/lib/classes/aaa/bbb_ccc_ddd.php''
# if aaa is a subsystem look for aaadir/classes/bbb_ccc_ddd.php or aaadir/classes/bbb/ccc_ddd.php
+
# if aaa is a subsystem look for ''aaadir/classes/bbb_ccc_ddd.php'' or ''aaadir/classes/bbb/ccc_ddd.php''
  
 
==Potential candidates==
 
==Potential candidates==

Revision as of 12:13, 26 May 2013

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

Moodle 2.6

Automatic Class Loading
Project state Proposal
Tracker issue n/a
Discussion n/a
Assignee Petr Škoda (škoďák)


Automatic class loading is a feature that eliminates manual includes of PHP files. It can be implemented only if you can derive the location of class from its name. Usually one class needs to be stored in one file.

This is a proposal for standardisation of class naming and class file storage in Moodle.

Benefits

  • improved coding style
  • lower memory footprint
  • enforcing of standardised class names and location of source files
  • option to replace standard classes in local customisations

Problems

  • lower performance because Moodle class names are ambiguous and plugin locations are dynamic

Plugin class naming

The general class name should be: plugintype_pluginname_typeofclass_someclass

Unfortunately the pluginname part might contain multiple underscores which may lead to several problems.

The algorithm for finding of the class file location from class name is:

  1. we have a class aaa_bbb_ccc_ddd_eee_fff
  2. aaa is always the plugin type, it can not be word core or moodle, ex.: mod, tool, block
  3. bbb is a candidate for plugin name, if this plugin exists look for file bbbdir/classes/ccc_ddd_eee_fff.php or bbbdir/classes/ccc/ddd_eee_fff.php
  4. if plugin or class does not exist bbb_ccc is another candidate for plugin name, loop for bbb_cccdir/classes/ddd_eee_fff.php or bbb_cccdir/classes/ddd/eee_fff.php
  5. continue until reaching the limit of underscores in plugin name (3 or 4?)

We need to somehow optimise this process to eliminate too some file_exists() calls in the algorithm above.

Core class naming

The general class name should be: core_optionalsubsystem_typeofclass_someclass

The algorithm for finding of the class file location from class name is:

  1. we have a class core_aaa_bbb_ccc_ddd
  2. look for file /lib/classes/aaa_bbb_ccc_ddd.php or /lib/classes/aaa/bbb_ccc_ddd.php
  3. if aaa is a subsystem look for aaadir/classes/bbb_ccc_ddd.php or aaadir/classes/bbb/ccc_ddd.php

Potential candidates

  • new events classes
  • admin settings in plugins
  • any new core feature implemented with OOP
  • addons in general

Implementation steps

  1. Finalise rules for class names, class file names and locations.
  2. Implement basic loader using current (slow) pluginlib API - such as https://github.com/skodak/moodle/compare/master...classloader.
  3. Improve performance and stability by rewriting get_plugin_types() and get_plugin_list() - it must be very fast and self-contained, it must not rely on MUC or any other library.

See also