[TYPO3-v4] TYPO3 boostrap for 4.6 and beyond

[Xavier Perseguers]

Hi,

> Entry points:
> * I'd personally like to start with removing the old caching, enable the
> caching framework by default for 4.6 and load it earlier to use it
> already in the autoloader.
> * I think it *is* possible to encapsulate global arrays in data classes,
> together with maintaining much backwards compatibility
> * Split current boostrap into smaller methods, refactor
> * Split config_default into a array definition class and a code class
>
>
> What do you think about all that? Who would like to step in?
> Looking forward to input and opinions,

After reading your two posts and the discussion so far, I really agree 
with your POV. I'm using the new CF for all my recent extensions and I 
agree that the tagging facility is really interesting. Having CF loaded 
by default sounds good.

I understand the concern of François who had the same feeling than me at 
the beginning. Moreover, CF was not that stable back when it was 
introduced (at the very beginning) but as it was largely advertised, I 
guess some people still have their initial mitigated experience in mind.

Regarding makeInstance, I had the same experience while prototyping a 
new SQL parser, calling it instead of "new" was a real performance 
killer. This is specially true when it comes to large domain models with 
really lots of classes instantiated to represent it, which is the case 
f.e. with any large use of DDD. It's really worth optimizing it unless 
we decide at some point to have a better approach to XCLASS. Still, I 
must say I quite like XCLASS because it allows official way of fixing 
something or backporting some needed feature. It should not be used in 
the long run but still, I really like it's simplicity.
Now, using another approach as already discussed many times in the v4 
list with mainly "v5-oriented" people would certainly lead to yet 
another overhead meaning we should not underestimate such widely used 
methods and business logic.

Replacing global arrays. This was discussed a few times. I remember the 
idea (that you mentioned too) of setting them to "read-only" at some 
point. Helmut and his team would certainly find this interesting from a 
security point of view. And having methods to add or remove extensions 
instead of playing with string operators within 'extList' would 
certainly be pleasant, although this comes again to the slow down of the 
system as more classes and small chunks of code are needed to be loaded...

Well, that's it! Thanks for your posting and looking forward to reading 
more on this before deciding where we are heading for 4.6 and above.

Xavier