[TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions

[Ernesto Baschny [cron IT]]

Ingo Renner wrote: on 18.09.2008 04:25:

> Well what's the difference to now? DB down => TYPO3 down, right?
> 
> Also of course we don't need everything they do. Drupal relies on 
> functions a lot, we don't, so we already only need to care for classes.
> 
> Of course it could be an option to have all class->file relations stored 
> in a huge array and then have that stored serialized. This however would 
>  slow down the system because of the huge array. I rather find it better 
> to look only the requested classes/files.
> 
> I don't know whether you noticed this fine bit, but they store which 
> classes/files were needed for a certain URL path/menu entry. We could do 
> this too when binding it to the cHash or the pageId, right? This would 
> totally justify the use of a DB, wouldn't it? You could look up all the 
> files needed for a page with a single query.
> 
> does that sound good?

I don't think that this would be possible. A page Id and even a cHash 
doesn't necessarily means the same classes will be needed. Some USER_INT 
might load random classes that change on each request. Pre-loading them 
all for a hit probably won't give much performance benefit. Lazy loading 
seems to me the best solution, meaning getting rid of all "require_once" 
statements throughout TYPO3 (and extensions) code. Everybody just calls 
makeInstance() and its friends. That should start the autoloading:

1) class is loaded already: use it.
Else:
2) search cache-array for an entry. Class found? load file, use it.
Else:
3) find a filename conforming our conventions where that class should be 
in?, load the file, class is loaded? use it.
Else:
4) rebuild the cache-array. Search cache-array again, found? use it. 
Will stop at step 2) next time. Not found? Error. Maybe add error-entry 
in cache-array so that it won't need to rebuild next time.

In my eyes we don't need to have a "huge" file->class array or database 
cache with information on all classes. We just need that information for 
exotic classnames which cannot be found by means of naming conventions. 
So if one sticks to our naming conventions, we won't store that in the 
search-cache:

- t3lib_TCEmain => t3lib/class.t3lib_tcemain.php
- tslib_feTCE => tslib/class.tslib_fetce.php
- tx_lowlevel_cleaner_core => 
EXT:lowlevel/class.tx_lowlevel_cleaner_core.php
- tx_sv_authbase => EXT:sv/class.tx_sv_authbase.php

But we will need to store the information (in 4) and use it (in 2) for 
stuff like:

- tslib_cObj => tslib/class.tslib_content.php
- FE_loadDBGroup => tslib/class.tslib_pagegen.php
- myclass => EXT:myext/file.php

etc. This will keep the cache "small" (by sticking to our naming 
conventions). I would store that in a simple classname => filename array 
in our temp_*localconf.php files.

Cheers,
Ernesto