Project

General

Profile

Actions

Feature #19192

closed

Add autoloading to reduce require(_once) calls

Added by Ingo Renner over 16 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
2008-08-04
Due date:
% Done:

0%

Estimated time:
PHP Version:
4.3
Tags:
Complexity:
Sprint Focus:

Description

requirements and ideas for autoloading in TYPO3 4.3:

  • use the SPL autoloading stack
  • build a registry of which class is in which file
  • use absolute paths for require()ing
  • keep track of loaded files - no double require_once
  • remove manual include/require statements in the core
  • make it possible to turn of cached lookups -> will slow down execution
  • maybe make it possible to en/disable certain cached autoloading (t3lib, tslib, extensions)
  • put registry creation code and autoloader into different classes, we do not need the registry creation code all the time

http://ilia.ws/files/phptek2007_performance.pdf
http://drupal.org/node/259623

mailinglist snippets:

IR = Ingo Renner
MK = Martin Kutschker

IR:
The problem with TYPO3 and its extensions is that we do not have a "default" filesytem structure how/where classes are located and how their files are named.
As you already wrote I agree that autoloading at least for t3lib, tslib, and typo3/classes/ (maybe some more) is quite easy.

However I think that we can also come up with autoloading for classes located in extensions that do not follow a certain schema or structure of placing classes in certain folders. (We should establish that though)

The idea I had is to recursivly run through all directories and see which classes are in which files. Collect this information in a kind of key => value "registry"/array. This collected information should then of course be stored somewhere (using the new caching framework maybe?!).

Every call of __autoload() would then be a matter of looking up where that class is located and loading that file. In addition __autoload() might (have to) keep track of which classes are loaded already. (because requiriing is slow)

I think that this method would be effective as the information of which class is stored where only rarely changes. Changes - in production environments - only happen when updating the installation and when (un)installing new extensions. When in a testing or development environment the caching of class/location mapping could be disabled.

=============================================================================

MK:
t3lib (maybe in config_default.php), TYPO3-BE (maybe in init.php) and
tslib (maybe in index_ts.php) all define their auto-loader function and
register them via spl_autoload_register().

The reason I suggest 3 fuctions is separation. These functions only look
for their prefix and have knowledge of the few irregularities where
class name and filename doesn't match.

=============================================================================

MK:
The only caveat is that t3lib and typo3/classes don't live in the ext.
directories and must be handled in an extra run. And don't forget that
it is for some reason possible to define the location of tslib via
constants (start of index_ts.php), but I don't mind if that feature goes
away.

=============================================================================

MK, finding classes in php files:
It's more or less a grep for "^class ([a-zA-Z0-9_]+) {" on all .php files.

(issue imported from #M9116)


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Feature #19180: Introduce a new caching framework (backported from FLOW3)ClosedIngo Renner2008-08-01

Actions
Related to TYPO3 Core - Feature #18548: Adding autoloadClosedOliver Hader2008-04-03

Actions
Has duplicate TYPO3 Core - Feature #19503: Implement autoloading for TYPO3ClosedOliver Hader2008-10-24

Actions
Actions

Also available in: Atom PDF