[TYPO3-project-4-3] autoloader using SPL

Ingo Renner ingo at typo3.org
Sun Aug 3 22:42:03 CEST 2008


Martin Kutschker wrote:

Hi Masi,

glad you brought this up again!

> I just noticed that the SPL extension has a stackable autoloader. I
> suggest we use this for t3lib, tslib and possibly typo3/classes instead
> of writing our own __autoload(). We could but we would clash with all
> other PHP5 autoload implementations and SPL is installed by default.

why would we?

Could you please go more into detail and explain how your autoloading 
mechanism would work?

In fact I already got an own idea which would work like follows:

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.

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 
installing new extensions. When in a testing or development environment 
the caching of class/location mapping could be disabled.


All in all I think that having autoloading in 4.3 is _a must_. When 
doing some profiling using xdebug + kcachegrind I found that one aspect 
that slows TYPO3 down a lot are the many many includes we do as each 
include means a hard disk read access - and we all know that HDDs are slow.


so far
Ingo

-- 
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2


More information about the TYPO3-project-4-3 mailing list