[TYPO3-core] Adding visibility to methods and variables within t3lib_tcemain?

Christian Kuhn lolli at schwarzbu.ch
Thu Jun 14 21:03:31 CEST 2012


Hey,


On 06/12/2012 10:23 AM, Tolleiv Nietsch wrote:
> I recently made two requests to add visibility information for all
> t3lib_tcemain methods and member variables [1], [2]. Christian brought
> up certain concerns that this should be discussed with the list before
> it's merged. Therefore I'll give you a short explanation what my
> motivation was to make these requests and afterwards you're invited to
> comment on it ;)
>
>  From my understanding especially t3lib_tcemain acts as public API to
> work with records in TYPO3 (even if that changed a bit with extbase).
> Therefore t3lib_tcemain should have a clear and clean API and that
> should focus on the purpose of that class.

I would love to see a better split and more slim tcemain / tceforms / 
tslib_content as well!


>  From what I see at the moment the API is cluttered and every attempt to
> refactor or clean it up can't be done without a preceding deprecation
> step 6 months before the actual refactoring. I guess you'll figure
> yourself why this is an issue.

Yes.


> For the two requests I figured out which of the t3lib_tcemain members
> and methods are currently used from the outside and then protected all
> others. What I see as the result is that some functional blocks (e.g.
> all the checkValue_* stuff) could now be moved out into separate
> classes, other methods could be turned to be "protected" with the normal
> deprecation procedure and some other known-to-be-public methods could be
> treated as such and receive some more attention in regards of
> input-validation etc.
>
> Still I agree with Christian, proceeding with the requests is not a
> small step but I think that 6.0 also enables us to make these (slightly
> breaking) changes without complex deprecation methodology.

The problem is bigger than just tcemain (but yeah, this class is one of 
the most important ones): metrics.typo3.org tells me, there are currently:
2948 methods missing scope
2041 member vars missing scope

In the end, we should aim for 0.

6.0 might be the chance to do so, but it will be a lot of work if we 
want to do it in a sane way, even if we start with only most important 
classes. Some parts are more critical than others. There are for 
examples some classes where we could reduce visibility more aggressively 
(for example in core extensions).

Still, it is fact that we introduce a massive API change if we just make 
methods / properties protected, and we _will_ face people complaining 
about broken extensions. This will be true even if we think twice about 
each and every part where we reduce visibility.

Currently, I'm still undecided if we can realistically take this path, I 
hope we get real opinions from more devs in this area! I tend to think 
that we can reduce visibility for 6.0, but I also fear a shit storm if 
we do not manage to do it in a sane way.


Regards
Christian


More information about the TYPO3-team-core mailing list