[TYPO3-core] Feature #9633: Implement autoloading for TYPO3

Oliver Hader oliver at typo3.org
Fri May 1 18:01:46 CEST 2009


Hi Bernhard,

Bernhard Kraft schrieb:
> Hello !
> 
> I have not digged very much into the autoloader problem, altough I
> totally agree the problem of "chain loading" almost all class files has
> to get solved.
> 
> For the above cited question I should note, that creating a "registry"
> should be something which is done either totally "automagically", or on
> a "clear class-cache" request.

Hm, why? The full-blown-registry of everything has to be updated, when
a) extensions are installed or removed
b) the TYPO3 Core has been updated to a newer version

This RFC has the following parts:
* using t3lib/core_autoload.php that contains a mapping to the files of
the TYPO3 Core. If new files are added to the core and do not support a
common naming scheme, they have to be added to t3lib/core_autoload.php
* using [extkey]/ext_autoload.php that contains a mapping to the files
of the accordant extension. If parts of that extension should use the
autoloader and do not support a common naming scheme, they have to be
added to ext_autoload.php.
* using a common naming scheme, that allows to determine the correct
path to a file automatically without the requirement of a registry file

Using the registry file is easy:
It's just a regular PHP array, no need to serialize/unserialize data
which makes autoloading slow - just add a new array element or use
extdeveval to rebuild the stuff.

Thus, the decision whether to use autoloading in extension is up to the
extension developer that provides the ext_autoload.php file or uses a
common naminscheme in his extension file structure. There is no need to
generate a registry file for all extensions even if they do not use
autoloading at all.

> In the case of "homebrewn" php parser or php-tokenizer I would opt for
> the php-tokenizer. AFAIK it is just a by-product of the php-engine - its
> the same code which creates the tokenizers output as which parses the
> executed php files ...
> 
> It would altogether be a good idea to have a class
> class.t3lib_parsephp.php to allow reading a php-file to a structured
> array representing the parsed file - this would easily allow to modidfy
> and clean-up all php files (like the "copyright 200x" problem, arising
> every year ...) Probably this class should go to extdeveval, and not
> into the core.

I agree, that it might be useful to have a e.g. t3lib_ParsePHP. However,
this belongs to a new feature request and different RFC. Furthermore the
"copyright 200x" problem can be solved by regular expression
find/replace as well.

olly
-- 
Oliver Hader
TYPO3 Release Manager 4.3


More information about the TYPO3-team-core mailing list