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

[Ingo Renner]

Martin Kutschker wrote:

Hi Masi,

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

yeah, I now read through the docs of the SPL autoloader. Quit 
interesting and more compelling than the standard autoload as it even 
falls back to the standard loader.
OTOH we shouldn't care for everything what people do in there extensions...

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

sounds good so far after having read the SPL autoload docs. I'm however 
not absolutely sure whether we'll need that - for other reasons than 
separation and maintainability.


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

It should at least be the basis we absolutly have to have.
However I think it could also be interesting to only load 
extension/plugin classes only when they're used on a page. What's more 
is that we could ease coding for developers when also offering 
autoloading for their classes.

Example:
Imagine an extension that teams up with tt_news. Now the classes of 
tt_news are needed only in a few cases by this extension - why should 
that extension always load tt_news' classes upfront just to be sure. 
Sure you could do an include only in the case you need it, f.e. when 
wrapping the include in an if statement but that doesn't look too clean 
to me. I rather prefer to have all includes on top of a file.


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

As written below, the number and location of classes only changes in a 
few situations... so this would be done only during these events. I 
would however clear that cache when clicking "clear all caches", too - 
just to be save.

>> In addition __autoload()
>> might (have to) keep track of which classes are loaded already.
> 
> Why? require_once() does that already.

Yes it does (or at least should), but I remember having read somewhere 
that it still does read the file even though it has been loaded before. 
Quite stupid actually.


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

but should be doable. I actually think that it's not a big deal.

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

they sure will have to be loaded but from that point on we will only 
load the classes we really use instead of loading classes "just in case 
we need them". Best example would be my recent caching patch which needs 
to include the exception class files just in case we need to throw one 
which is likely not going to happen with each request.


hope this clears up the issue a bit more =)
Ingo

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