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

[Martin Kutschker]

Ingo Renner schrieb:
> 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?

Some extension could intergrate a 3rd party lib that implements an
__autoload function. But thinking again this lib would also break our
SPL implementation. OTOH if both TYPO3 and the 3rd party libs use the
SPL mech everything's alright. So SPL is safer than a plain __autoload()
implementation.

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

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.

> 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.

And this is IMHO good enough.

> 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?!).

At run time or at install time? I think doing that during the
installation would be ok.

> In addition __autoload()
> might (have to) keep track of which classes are loaded already.

Why? require_once() does that 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.

Interesting idea. The lookup for extension classses could be done via an
additional SPL loader within the EM.

It's probably a matter of taste if t3lib/ and typo3/classes are also
scanned by the magical class finder.

Your solution is definitely more ambitious.

> 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.

Does that mean you want to remove all/most "manual" file inclusion and
rely wholly on autoloading? But how will this decrease file access? The
files will still have to be loaded.

Masi