[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